Subject: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

From: Peter Koch <[email-masked]>
Date: Wed, 22 Apr 2009 20:13:36 +0200

this is to initiate a working group last call on

        "DNSSEC Trust Anchor Configuration and Maintenance"
	 draft-ietf-dnsop-dnssec-trust-anchor-03.txt

ending Friday, 2009-05-08, 23:59 UTC.  The tools site gives easy access to
diffs and such under
 <http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03>.

The document is aimed at a status of "Informational".

Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.
There will be a five reviewer threshold.

-Peter [for the wg chairs]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Apr 2009 14:45:49 -0400

>  <http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03>.

I keep forgetting this bit of document jockeying - can an Informational use
RFC 2119 terms in a normative way?

...
#3.  Trust Anchor Priming

    ...
#  3.  Verify that the DNSKEY RR corresponding to the configured trust
#      anchor (i.e., the DNSKEY whose hash is configured) appears in the
#      DNSKEY RRSet and that this DNSKEY RR has the Zone Key Flag
#     (DNSKEY RDATA bit 7) set.  (This bit only indicates that the
#      DNSKEY is allowed to sign the zone.  This DNSKEY may or not be a
#      zone signing key.)

Last sentence? - "This DNSKEY might not be a zone a zone signing key.")

But I'm not sure what is meant.  At first the paragraph reads - make 
sure the Zone Key Flag is set and later says it "may or [may] not be 
a zone signing key."

Do you mean that "this" key could be a "key signing key?"

#  4.  Verify that the DNSKEY RRSet is signed by one of the DNSKEYs
#      found in the previous step, i.e., that there exists a valid RRSIG
#      (cryptographically and temporally) for the DNSKEY RRSet generated
#      with the private key corresponding to the DNSKEY found in the
#      previous step.

And here, are you saying that "this DNSKEY RR"'s private companion 
has to sign the key set for all this to work?  In step three you 
refer to a singular ("this") key, in step four it is plural ("is 
signed by one of the").

...
#  For this reason, old trust anchors SHOULD be removed from a
#  validating resolver's trust anchor list soon after the corresponding
#  keys are no longer used by the zone, as described in RFC 5011
#  [RFC5011].

Recommend that the priming be done often enough to capture revoked
DNSKEY RR's - so that the zone doens't have to keep them indefinitely.

# 4.  Trust Anchor Maintenance
#
#   Trust anchors correspond to zones' key signing keys and these keys do

  <keeping the terminology clean>

Trust anchors *could* be zone signing keys.  Still I think you want 
this here - SEPs?  Is that what is meant?

(RFC 4034:
2.1.1.  The Flags Field

...
    Bit 15 of the Flags field is the Secure Entry Point flag, described
    in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
    key intended for use as a secure entry point.  This flag is only
)

# 5.  Security considerations
#
#   This document proposes a standard format for documenting DNSSEC trust
#   anchors.

I didn't see a standard format (a la a zone file).  Just "use the DS 
fields."  Perhaps I was expecting examples and such.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Apr 2009 11:57:28 -0700

>RFC 2119 terms in a normative way?

Unfortunately, yes. When I have pointed out that it a semantic layer violation, the response is usually along the lines of "oh, you standards pedants are just so cute (sometimes)". In other words, there is no problem with us using it here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Apr 2009 15:05:02 -0400 (EDT)

> non-support to the WG mailing list.

It seems a comma is missing between Scott's name and mine.

One issue came up recently with the dnssec-conf package related
to Section 4, Trusted update mechanism..

If an OS ships with preloaded trust anchors, and the medium is
used over a year after it was created, eg an old CD/DVD copy, it
might cause DNS to complete fail due to loading rolled over
trust anchors. This DNS failure will prevent it from obtaining
an updated trust anchor update if those reside within one of these
zones.

The question is what to do, or what to recommend. For Fedora/EPEL,
I'm leaning towards automatically disabling all trust anchors (which
includes DLV) if the package build date is older then 9 months. At
the same time, we will commit to releasing at least a new package
every 6 months, even if no changes were made and we are just bumping
the release number. Upon package update, the resolver is restarted
and the same check that disabled the trust anchors before will now
accept the new package date, and enable trust anchors again.

It might make sense to add a warning about this issue in the RFC?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Apr 2009 12:17:56 -0700

>It might make sense to add a warning about this issue in the RFC?

Yes. For example, Ubuntu server "long term stable" releases are only put out every few years. If you pick one of them, you start off with an old image, then *hopefully* update as soon as you install. But, if you just turn on some services, this will be a problem that is quite different than the typical "but you might be running unsafe binaries".

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott Rose <[email-masked]>
Date: Thu, 23 Apr 2009 08:39:17 -0400

I have read the doc and support it.  Some minor comments/suggestions
based on Ed's message:

> sure the Zone Key Flag is set and later says it "may or [may] not be a
> zone signing key."
> 

I might suggest the last two sentences read:
(This bit only indicates that the DNSKEY is allowed to sign zone data.
This DNSKEY may or may not be a zone signing key (ZSK) as defined in RFC
4641 [RFC4641])

If the intention was that the trust anchor may be a ZSK or a KSK, but
they must have the zone signing bit set either way.  Then have RFC 4641
as a ref.  Although with RFC4641-bis being worked on, that may quickly
become dated...

Also, as Paul pointed out, it looks like Paul and I are one person with
a long name.  :)

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Joe Abley <[email-masked]>
Date: Thu, 23 Apr 2009 14:49:47 -0400

On 22-Apr-2009, at 15:17, Paul Hoffman wrote:

> Yes. For example, Ubuntu server "long term stable" releases are only  
> put out every few years. If you pick one of them, you start off with  
> an old image, then *hopefully* update as soon as you install. But,  
> if you just turn on some services, this will be a problem that is  
> quite different than the typical "but you might be running unsafe  
> binaries".

Perhaps software vendors ought to arrange their own distribution of  
trust anchors using trust tokens whose lifetimes suit the software. It  
seems likely that one size will not fit all.

For example, Ubuntu might require a package to be retrieved and  
installed after installation containing current trust anchors before  
it is possible to turn on validation. That package would presumably be  
authenticated using a key shipped with the OS whose lifetime is  
predictable in the context of the OS (e.g. a PGP key whose public  
portion is shipped on the install media, and hence which might be at  
least as trustworthy as the the rest of the OS installed from the same  
bit of plastic).

I don't like the idea of incorporating magic numbers (e.g. "nine  
months") algorithmically when trying to determine suitability of an  
old trust anchor. That seems likely to result in unnecessarily  
collateral damage in the event of an emergency KSK rollover.

I don't ship software, so I don't know how practical this general  
advice is. But it seems like a bad idea to package trust anchors  
administered by others with any piece of software, if there's a chance  
that those trust anchors are going to form a circular dependency in  
the process of updating them.

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 23 Apr 2009 16:03:40 -0400

> There will be a five reviewer threshold.

I have read this document and find it well-written and useful. A few  
somewhat minor improvements occurred to me, notes for which can be  
found below. I don't think any of them are tremendously substantive,  
and I think the document would still be accurate and useful if  
published as-is. I apologise for not reading the document and  
commenting earlier. I would be happy to suggest text in relation to  
any of the points below, if that seems useful.

In the second paragraph of section 1, there is an assertion that root  
zone signing is a prerequisite for "widespread public DNSSEC  
deployment". The text goes on to discuss islands of security. I am the  
last person to suggest that the root should not be signed yesterday,  
but I think it's possible for there to be widespread DNSSEC deployment  
without a signed root zone -- you just have more islands of security.  
I think that paragraph could be tidied up a little to make it clearer  
that the content that follows is useful without a signed root zone,  
just as it is useful with a signed root zone.

As I read section 2 I found myself expecting to see an example (as  
someone else here also mentioned). Perhaps this is because of the  
reference to the root hints file in the preceding section; the  
analogous advice there gives a presentation format (canonical zone  
format) while section 2 does not: it only provides guidance as to the  
type of data that should be used. I think the presentation format  
should be specified, with an example.

Section 4 does not provide guidance about updating a local trust  
anchor repository (e.g. a text file) based on the results of the trust  
anchor priming procedure which is described there. This seems like an  
important step; otherwise restarting a validator which has a really  
old trust anchor stored on disk might suddenly result in a priming  
failure, because of a key rollover elsewhere. I think storing updated  
trust anchors is implied by the text, but never really called out  
explicitly. I think explicit mention of it would be useful.

Given the apparent popularity of the IANA ITAR it might be worth  
mentioning it as one of the examples of a trusted update mechanism  
that does not use the DNS for trust anchor retrieval.

DLV provides another mechanism for obtaining trust anchors that a  
validator could use. It seems plausible that DLV could also be  
mentioned as another kind of DNSSEC In-Band Update mechanism, in  
addition to 5011.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Apr 2009 19:30:00 -0700

>There will be a five reviewer threshold.

I support the publication of this document. Some comments:

Section 2: "Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to enter manually, either by typing or cutting and pasting." I don't know of anyone who can accurately type Base64 for more than a few bits worth. I agree that cut-and-paste of Base64 for DS is easier than for a DNSKEY.

Section 3: "Priming can occur when the validating resolver starts, but a validating resolver SHOULD defer priming of individual trust anchors until each is first needed for verification." I disagree with this as a SHOULD; "may want to" is much more appropriate. I see nothing wrong with wanting to get the first round of crypto out of the way at startup.

Section 3: "Following are the steps a validating resolver SHOULD take to prime a configured trust anchor:". What do you propose they do if they don't follow the SHOULD? All four of those steps feel pretty damn required.

Section 4, "Trusted update mechanism": "This mechanism is realistically only feasible for updating a small number of trust anchors, such as for the top-level domains." That statement is conjecture unsupported by facts. What is so hard about doing this for a few thousand trust anchors? The queries will be spread over hours (if not weeks). Maybe remove the sentence, or soften it.

--Paul Hoffman, Director
--VPN Consortium