[dnssec-deployment] About "no validation" for DNS root signing strategy
eoster at CS.UCLA.EDU
Mon Oct 12 14:38:12 EDT 2009
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 . 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20091012/746e4397/attachment.bin
More information about the Dnssec-deployment