[ietf-dkim] protecting domains that don't exist

[Dave Crocker]

Jim Fenton wrote:
> Dave Crocker wrote:
>> I keep waiting for proponents of this 'feature' to solicit technical 
>> review from independent DNS and security experts, for assessing the 
>> likely benefit as balanced against the likely cost.
> 
> I have been soliciting technical review from the DNS folks, literally, 
> for years, on this and prior iterations. I recall quite clearly a 
> lengthy discussion I had with Peter Koch at IETF 65 in Dallas just over 

Excellent.  So it will not be difficult to document that formal review so that 
the rest of us can consider its careful documentation of the DNS community's 
assessment of the peculiar mechanisms defined in the working group draft.

The point behind my probe for formal review was just that:  formal review. 
Casual, private conversations might be a precursor, but they are not 
sufficient, particularly when seeking to modify the DNS's exact-match paradigm 
for queries.


> two years ago. I have been less concerned with independent security 
> review, since we are in that area and I expect that will happen with the 
> specification as a whole, not just this aspect of it.

Jim, waiting until we are done, to get buy-in from the rest of the security 
community is singularly ill-advised project management.  It maximizes risk and 
minimizes benefit, particularly when there is very basic concern over the 
efficacy of what is being proposed.

I realize that you are not the one with the concern, but you might have 
noticed that there are others in the working group who do not share your comfort?


>>> The requirement to publish large numbers of ADSP records is a barrier 
>>> to its widespread adoption
>> That's a view I do not recall seeing phrased quite that way before.  
>> It's nicely succinct and pragmatic.  The only question is where is its 
>> basis and, again, the broad support for the assessment that 
>> substantiates it?
>>
>> For example, John has provided some counter-arguments suggesting that 
>> the actual, incremental effort to deal with a large number of 
>> parallel, related domains -- for this particular RR -- is not all that 
>> high, particularly in light of the core requirement for change to 
...
> I don't see an analysis for John's assertion either.

When seeking to add something to a specification, the burden of establishing 
that it is necessary or, at least, beneficial, falls on those who are 
proponents.  Additions create costs. In the case of Internet standards, the 
costs are large-scale and long-term.  The costs need to be justified.

Let me anticipate a counter-argument that might be put forward:  The feature 
in question is already in the specification so the challenge is in 
establishing that it must be removed.  The problem with this view is that 
there was never a clear consensus to add it.  Really.  I've asked for 
documentation to the contrary and it has not been forthcoming.


>>> broad coverage for domains.  This can be addressed with tools, but 
>>> the requirement to add tooling to achieve good ADSP coverage is also 
>>> a deployment barrier.  
>> As John noted, there is already a requirement for modifying tools, in 
>> order to support ADSP.
> 
> Not DNS tools. The requirement to modify DNS tools to achieve broad 
> coverage would be an additional requirement.

I don't understand your response.


>>> Similar concerns led the WG to the use of TXT records rather than a 
>>> new RR.
>> Not really. The infrastructure barrier to support of a new RR exists 
>> with both those who create the record as well as those access it.
>>
>> The barrier for ADSP is only with those who create the record.  Very, 
>> very different dynamic.
> 
> Agree that ADSP requires changes only on the publication side. I still 
> believe that this introduces a significant barrier.

Having to make any changes to DNS administration is a barrier.  Right.

And your point is what, exactly?

The current point was not whether there was any barrier at all, but rather it 
was about your attempt to equate the height of the barrier for a new RR with 
that of a new use for an existing one (TXT).  My response was that they are 
massively different barriers.


>>>     There are a lot of DNS management tools out there that would need 
>>> to change in order to publish the necessary ADSP records, and this 
>>> would take considerable time.
>> They already need to change, to support one record (for one domain.)  
>> How is there something fundamentally worse about having to support many?
> 
> The tools don't need to change; the additional TXT record for ADSP can 
> just be published independently using existing tools.

Jim, some DNS admin tools do not automatically permit that.  They need to be 
changed.


> We have two approaches to this problem, one approach which requires more 
> effort on the part of ADSP publishers (either manual publication of 
> additional records or deployment of new DNS tools), and one approach 
> that requires more effort on the part of ADSP users, although that 
> effort is largely contained within the software implementing ADSP and 
> transparent to the deployer. Let's just treat this as an engineering 
> tradeoff.

Yes, let's.  But let's do that in a discussion with substance, rather than a 
wave of the hand, which is frankly what I think the above paragraph represents.

An engineering tradeoff decision needs an engineering costs/benefits discussion.

For the current case, the choice is between a possible burden on what is 
probably a small number of administrators, versus a very real real-time 
overhead burden on virtually every email exchange over the open Internet... 
forever.  Worse, the burden is not likely to have accompanying benefits.



> I'm rather surprised this has become such an issue for you and John 
> since this same approach is used in draft-levine-asp-00, which John 
> edited and on which you collaborated.

Here, you move into a kind of process challenge, and even toss in some ad 
hominem.  Citing only John and me also nicely seeks to marginalize the concerns.

More importantly, you seem to have missed or forgotten a number of my own 
postings that explain what is motivating the concerns.

So let's review some history about *technical* and *operational* concerns:

On 11 April, Dave Crocker wrote (to you privately):
 > Have you considered the relative costs (and benefits)?
 >
 > who has to publish the extra records?  for how many of these will that
 > be onerous?
 >
 > who will do the extra queries? for how many queries will the extra
 > overhead be useful?

Did these not seem sufficiently basic or legitimate questions?  They ought to 
explain my own reason for pressing concerns about these extra DNS details.

How about my 9 April posting to the list:
> Dave Crocker wrote:
>> Given that the DNS is not designed to permit this conveniently and, in 
>> fact, does not seem to me to be able to do it at all, we certainly need 
>> a complete and coherent technical description of how ADSP accomplishes 
>> complete coverage of a sub-tree.
>> 
>> This would describe the approach being taken for covering a sub-tree, 
>> and the component mechanisms being used to achieve it -- Step 2 is but 
>> one of those components. It would also demonstrate what kind of attacks 
>> it protects against.
>> 
>> I am not aware of any previous technology providing such sub-tree 
>> functionality, and so this ought to be subject to careful review by the 
>> DNS and Security folks.  At that, I fear it will nonetheless warrant a 
>> status of "experimental".
>> 
>> So in terms of a "goal" I'm probably in agreement that it would be dandy 
>> to do.   But I think that my desiring that goal is pretty much irrelevant.
>> 
>> The problem is that I believe there is no technical means of covering a 
>> subtree completely, except by case-analysis, which isn't covering a tree 
>> at all.
>> 
>> I believe the Step 2 query only makes sense for ADSP in the context of 
>> covering an entire sub-tree, but that ADSP does not describe the larger 
>> framework into which Step 2 fits, for accomplishing that goal.


How about 2 March:
Dave Crocker wrote:
 > Put forward as an efficiency hack, to avoid having to make a number of
 > one-level-down DNS records, the mechanism has no claim towards affecting
 > security.  Taken on its own, therefore, the question is whether the
 > mechanism as a) worth the effort on a normal implementation cost vs.
 > operational benefit basis, and b) worth the effort to run contrary to
 > established DNS practice and, now, IAB preferences.
 >
 > Put forward as having any security characteristics, such as enforcing
 > the ASP security model, this DNS hack is likely to have quite a bit of
 > pushback, as you note.

I seem to recall other, earlier and similar postings, but these ought to 
suffice, both to explain why the matter is being pressed and that pressing the 
matter is being spontaneously generated.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net