[dnssec-deployment] About "no validation" for DNS root signing strategy
roy at dnss.ec
Mon Oct 12 06:14:58 EDT 2009
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 . 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.
More information about the Dnssec-deployment