[Dnssec-deployment] Signed TLD status
ailiop at lsu.edu
Tue Sep 28 11:51:59 EDT 2010
On Tue, Sep 28, 2010 at 09:57:46AM -0400, Edward Lewis wrote:
> There are two questions that need to be answered. One, is there an
> RRSIG for the RR set? Two, should there be one? The first question
> is pretty obvious, did you get one or not. The second one is
> whether the deliver is "germane."
..and it is exactly the question of "should there be one" or not,
i.e. is the zone expected to be secure, that drives the requirement
for secure chaining.
> This isn't a problem because I can build a chain of trust via
> KSK(7)1 or KSK(8)1. It's important that algorithms chain, not keys.
> The reason algorithms have to chain is that a validator might only
> be "literate" in (7) or only in (8), hence the source of the sets
> can't assume the validator will change algorithms with in a chain -
> although a validator is free to do so.
..but this is a very particular case, i.e. the one that:
- yes, there is a dangling DS in the parent zone, not pointing
to any DNSKEY in the child
- BUT, there exists a fine, provable chain from parent to child
that can be used to complete the authentication: KSK(7)1
and that of course, changes the scenery significantly. In all
previous discussions, the basis is that there is a dangling DS
in the parent, no matching DNSKEY in the child, and no other
DS/DNSKEY pair available for authentication, and that's a very
> It's not that DNSSEC is opportunistic, it's that if you tighten up
> the security to require exact matches, you force the entire
> operations hierarchy to work in lock step rhythm. The reason DNS
> has scaled well is the loose organization, if DNSSEC breaks that,
> the whole system fails. Securing that is useless.
I agree that the loose coupling has been one of the success factors
for DNS. I don't agree that security should not be tightened. "Lock
step rhythm" is just a generalization, but in reality there are several
timing considerations to be taken into account, which are unfortunately
part of the deal, and perhaps somewhat hard to get right. Indeed, it
makes DNS break in new ways, but that means that everyone needs to pay
closer attention to TTLs and proper timings.
Sure, there can be numerous mishaps, since the DS is served by a
different nameserver than the one serving the DNSKEY. That does not
mean that failure to match those is always soft failure. Any mature
iterative resolver implementation should be able to cope with these
(if we are actually talking about things like previously cached
security material, or transient network errors preventing comms).
I could also claim that securing without really securing is equally
useless. How can a validator ever assure that a reply is provably
insecure, unless there are strict validation rules in place ?
> Bogus to me has always been - determining that the data should be
> signed and I can't finish off the chain and I'm out of options.
> ("Options" includes looking again for the missing piece elsewhere.)
> I never encourage one to accept insufficient data - downgrades are
> not what I'm opening up to. There has to be an established and
> appropriately built and terminated chain, but, you have to allow for
> a lot of "barbs" in the chain because of the disjoint nature of DNS
> Does this clear things up more?
I see your point; I believe that any sane validator implementation
will allow for "barbs", meaning that an alternative path of trust
grants the required assurance, and can safely override a dangling DS
of the same algorithm. That's a different case than the one noted
above, and discussed. If you lose the ability to reach the "provably
insecure" status, then there is no protocol security.
Still, I think that it really depends on what you expect out of
the actual DNSSEC assurance. If we are talking about name-to-ip
mapping guarantees, then apparently it is not very interesting
to have such rigid rules. The expectation is to leverage DNSSEC
assurance for other protocols outside DNS though. Things like SSHFP
are more naive forms of it, other things, like the ietf-keyassure
efforts, are pointing towards something far more serious.
More information about the Dnssec-deployment