[Dnssec-deployment] Signed TLD status
Ed.Lewis at neustar.biz
Wed Sep 29 13:58:54 EDT 2010
At 9:44 -0700 9/29/10, Casey Deccio wrote:
>A case in point is hudoig.gov, which currently has the following setup:
>alg 7, id 52533
>alg 5, id 57833
>alg 7, id 52533: (corresponds to DS, and signs only DNSKEY RRset)
>alg 5, id 57833: (corresponds to DS, but is not signing anything)
>alg 5, id 48526: (no DS, used to sign DNSKEY RRset and SOA RRset)
>The apex DNSKEY RRset is not signed by both algorithms (5 and 7)
>appearing in the DS RRset; it is only signed by algorithm 7. Also,
>there is no chain from the SOA RRset to a DS of each algorithm.
It's like going to the eye doctor. "Cover one eye" - i.e., what if
the resolver only knows algorithm 5?
alg 5, id 57833
alg 5, id 57833: (corresponds to DS, but is not signing anything)
alg 5, id 48526: (no DS, used to sign DNSKEY RRset and SOA RRset)
From this, a validator would conclude that the RRSIG(DNSKEY) for key
57833 is missing (possibly stripped), thus should return SERVFAIL for
anything below this point in the DNS tree.
>In the strictest sense, I would expect a validator to respond with a
>bogus response for the DNSKEY RRset and the SOA RRset. unbound
>authenticates the DNSKEY RRset, but not the SOA RRset, perhaps
>indicating that it is okay with the dangling algorithm in the DS
>RRset, but not with the lack of a chain with a single algorithm from
>SOA RRset to DS. Would unbound validate the SOA RRset if DNSKEY 48526
>were of algorithm 7?
>BIND validates both as authenticated data, so it seems to be okay with
>the dangling algorithm in the DS RRset and the fact that a DNSKEY with
>algorithm 7 is authenticating a DNSKEY with algorithm 5, which then
>signs the SOA RRset.
Now, a validator that understands algorithm 7 could build a chain
through this point. It's not up to the validator to worry if the
serving element is correctly configured but whether it can rely upon
the data that it got for the client element that asked.
A validator that understands algorithm 7 and raises an alarm about
this is a "busy body" and "should mind it's own business."
>As a developer of tools for DNSSEC analysis, I've tried to balance
>validation optimism (i.e., is there *some* path to a trust anchor?)
>with comprehensiveness (i.e., are there actual or potential problems
>with some links in trust chain?). At this point, my output with
>regard to multiple algorithms most closely resembles the behavior of
>unbound, in that a chain must follow a single algorithm to a DS for an
>RRset to be properly authenticated:
>http://dnsviz.net/d/hudoig.gov/dnssec/ . Obviously this should match
>with implementation to be useful, but I would like it to match
>specification as well.
Tools for analysis are another matter. They are supposed to be "busy
bodies" and "poke their nose into other's busines." It's good to
tell an operator "you're stuff is sufficent for users of BIND 9.7 but
not for BIND 9.5" as well as "to be fully compliant you should do
Tools and validators are different beasts. They work for different
masters (tools for producers/servers, validator for
>Is the RFC requirement in place simply to accommodate varying levels
>of validator support for different algorithms, as was alluded to
>earlier in thread, or does it have to do with algorithm downgrade
>attacks, or both?
Specifically to prevent downgrade situations.
If the validator is fluent in 5, has a trust chain to the parent and
the parent is using 5, the validator can then reliably deduce that a
child who's DS set has only algorithm 7 (because it is signed by the
parent's 5) is going to appear to be unsigned/insecure to the
validator. If the DS has 5 and 7, then the child is signed/secure to
If we allowed the child to use 5 OR 7, then the validator can't
decide (in the theory of computing sense) whether the non-arriving
signature was omitted by the source or stripped by an
attacker/non-DNSSEC capable element. To remove this ambiguous state,
we require that a zone be totally signed PER ALGORITHM or be unsigned.
>The snippet I took from the RFC above only mentions DS RRs, but not to
>SEPs in general (i.e., to include trust anchors). Does the same
>requirement hold for these as well? How will things like RFC 5011
>work for algorithm rollovers?
Trust anchors are in the domain of the validator. Validators can
pick and choose the algorithms they decide to live with. So, no.
The deal is - the supplier has to supply data in a way that will let
the receiver be able to conclude deterministically "what's up" given
the lack of a reliable transport protocol and anonymous (and
therefore untrustable) intermediate caches.
NeuStar You can leave a voice message at +1-571-434-5468
Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?
More information about the Dnssec-deployment