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

[Roy Arends]

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.

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

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.

>  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 these guys have developed a deployment scenario that is very  
methodical and conservative.

Kind regards,

Roy Arends