[dnssec-deployment] About "no validation" for DNS root signing strategy

[Eric Osterweil]

Hey Roy,

On Oct 12, 2009, at 3:14 AM, Roy Arends wrote:

> On Oct 8, 2009, at 8:40 PM, Eric Osterweil wrote:
>
>> On Oct 8, 2009, at 10:32 AM, Jakob Schlyter wrote:
>>> the intention with the DURZ, the Deliberately Unvalidatable Root  
>>> Zone, is that it should be obvious to everyone that it is not  
>>> possible to validate the signatures.  I do not know of any  
>>> resolver that would try to validate signatures, even though you do  
>>> not have a trust anchor configured, so to get any sort of  
>>> validation failure you have to actually configure the bad key.
>>>
>>> we have considered using another algorithm identifier, but there  
>>> are currently no experimental identifiers [1]. we did consider  
>>> using a private algorithm, but decided that it could have other  
>>> issues as well.
>>>
>>> 	jakob (part of the design team together with Matt, Joe and others  
>>> at ICANN/VeriSign)
>>
>> So, this is more than just a little bit scary.  The protocol is  
>> already reasonably complex, but the notion that it's OK for  
>> signatures to not validate sometimes is a very slippery slope.
>
> Eric, these signatures are valid signatures. These signatures  
> validate, provided that the proper key is used. I understand that  
> the idea behind not publishing the proper key is to _avoid_  
> validation while the signed zone has not propagated to all the root- 
> server instances. I also understand that the idea behind publishing  
> a false key is that this setup provides for traffic measurement that  
> closely matches real deployment.

I actually (after looking at the presentation that was posted after I  
composed the above message) I think I understand what is being  
proposed, and fwiw, it sounds clever.  My main objection is that the  
semantics are not at all captured by the DNSSEC rfcs/drafts.  So, this  
is an undocumented exception case.  I don't object to the there being  
more intricacy in the protocol (though I worry about it), but the  
notion that experts understand this and novices need to look at base64  
to grok that this is an "allowed exception" sounds a little  
worrisome.  Why not post-date the signatures so that the inception  
doesn't validate any zone data until some time in the future (even if  
that the data is not going to be served then)?  Then everything is  
totally DNSSEC rfc compliant.

>
> Obviously, where things go wrong is when this false key is blindly  
> aggregated and then sold-off as something trustworthy, like a  
> 'better' alternative to DLV, such as mentioned here: http://tr.im/BvVN

hmm...  I'm not sure 'better' is stated there.  I think is just states  
the project's beliefs.  :)

>
> Needless to say, any trust-anchor that is to be configured locally  
> should be inspected via some out-of-band means. This false key even  
> has warnings in its key-material (clever!), and will likely have  
> sites associated with it that will inform you that this is a false  
> key.

I wouldn't mind discussing this issue again, but I wouldn't want to  
conflate multiple conversations at the expense of any of them. :)

>
>> If nothing else, it's a new corner case that introduces a very  
>> dangerous avenue.
>
> What corner case? Where does this go 'wrong' in an unexpected way?  
> What dangerous avenue?

I think overloading a record type (such as a crypto key) to be english  
is odd (not necessarily dangerous).  When a crypto system is designed  
to validate data but signatures are published so as not to validate, I  
think it's strange to be subverting the design, but I can now see why  
one might do this.

However, resolver software can't read, so it can't understand when a  
key is logically bogus.  I think requiring human intervention to  
understand that a validation failure is OK is suboptimal (esp at  
scale).  I think if the protocol can be made to understand what an  
exception case is, then the solution is much better.

>
> I think these guys have developed a deployment scenario that is very  
> methodical and conservative.


No disagreement, I just suggest that this ought to be formally  
documented before it comes to life in production.  W/o that, there are  
details that can be considered, "open to interpretation," imho.

Eric
é

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20091012/746e4397/attachment.bin