[Dnssec-deployment] Signed TLD status

[Edward Lewis]

At 9:44 -0700 9/29/10, Casey Deccio wrote:

>A case in point is hudoig.gov, which currently has the following setup:
>
>DS
>alg 7, id 52533
>alg 5, id 57833
>
>DNSKEY
>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?

DS
alg 5, id 57833

DNSKEY
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 
this".

Tools and validators are different beasts.  They work for different 
masters (tools for producers/servers, validator for 
consumers/clients).

>Some questions:
>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 
the validator.

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
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?