Subject: [DNSOP] comments on draft-ietf-dnsop-dnssec-trust-anchor

From: Patrik Wallström <[email-masked]>
Date: Thu, 11 Nov 2010 10:51:04 +0800

I have reviewed the trust-anchor document, and have some comments. I am not sure if this issue has been up for discussion.

The following statement is in section 2:

  "Specifying a trust anchor using a DS format instead of a DNSKEY
   format offers an advantage because it forces the resolver to make a
   DNS query to obtain the trust anchor's complete DNSKEY RRSet during a
   priming operation (described below).  If only a DNSKEY record were
   specified, resolver implementers could conceivably avoid priming the
   trust anchor.  But priming is desirable because it causes the
   resolver to retrieve an up-to-date version of a zone's DNSKEY RRSet
   from one of the zone's authoritative servers.  It should be noted
   that in practice, priming is frequently required, when the data in
   the trust anchor zone is signed with a different key than the one
   configured as the trust anchor."

I fail to see how priming is the solution to up-to-date keys, either you trust the key or not. It's the signatures over the DNSKEY RRSet that forces the resolver to prime the DNSKEY for the zone, if there is missing keys. So the priming using the DS is a non-issue here.

and also this:

  "Using a DS format is also recommended because it is smaller than the
   DNSKEY format and is easier to compare manually, either by typing or
   cutting and pasting."

This seems to be the major reason for wishing to use the DS as a trust-anchor for a resolver. But I don't believe that this is not a good enough reason for avoiding the use of DNSKEY as a trust-anchor. In the case of using the Root or TLD trust-anchors, in most cases you also have to verify the key by other means, for example cryptographic signatures. These are also not easy to read, so you still need tools, copy&paste or file transfers to verify the key. The "easier to compare" argument fails me here.

Using DS as the forced trust-anchor mechanism adds a lot more complexity to this document, for example the whole of section 3, and to be fair, I cannot really see the advantage.