[Dnssec-deployment] Signed TLD status

[Casey Deccio]

On Wed, Sep 29, 2010 at 12:27 AM, W.C.A. Wijngaards <wouter at nlnetlabs.nl> wrote:
> If there is a dangling DS, but another DS works fine (with the same
> algorithm), then unbound will use the working DS.
>
> It is also allowed to have KSKs in the child zone to which no DS record
> points.  (as long as the zone is signed with a key of each algorithm;
> this means that for algorithm rollover you should also introduce a ZSK
> for that algorithm).
>

Regarding multiple algorithms... there seem to be varying
interpretations of and levels of adherence to RFC 4035:

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

Together with the requirement that at least one DS of each algorithm
must map to a valid DNSKEY in the child zone, this implies that for
every RRset in a zone, a chain of trust must extend to a DS in the
parent zone using each of the algorithms existing in the DS RRset.
Additionally, each RRset must be covered by an RRSIG for each
algorithm existing in the DNSKEY RRset (even if the DNSKEY is not used
to sign the DNSKEY RRset?).

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.

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.

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.

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?

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?

Regards,
Casey