Subject: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

From: Joe Abley <[email-masked]>
Date: Wed, 29 Sep 2010 12:47:21 +0000

FYI

Begin forwarded message:

> From: [email-masked]
> Date: 29 September 2010 12:45:03 GMT
> To: [email-masked]
> Subject: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt 
> Reply-To: [email-masked]
> list-id: Internet Draft Announcements only <i-d-announce.ietf.org>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : DNSSEC Trust Anchor Publication for the Root Zone
> 	Author(s)       : J. Abley, J. Schlyter
> 	Filename        : draft-jabley-dnssec-trust-anchor-00.txt
> 	Pages           : 16
> 	Date            : 2010-09-29
> 
> The root zone of the Domain Name System (DNS) has been
> cryptographically signed using DNS Security Extensions (DNSSEC).
> 
> In order to obtain secure answers from the root zone of the DNS using
> DNSSEC a client must configure a suitable trust anchor.  This
> document describes how such trust anchors are published.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jabley-dnssec-trust-anchor-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: David Conrad <[email-masked]>
Date: Wed, 29 Sep 2010 12:04:00 -0400

Hi Joe,

Useful draft.  A couple of comments/questions:

In section 2.1:

"The document contains a complete set of
   trust anchors for the root zone, including anchors suitable for
   immediate use and also historical data."

This strikes me as asking for trouble after the trust anchor is rolled.  I'm not sure we want to codify ephemeral information like a trust anchor in an RFC.

In section 2.2:

"  Each CSR will have a Subject with following attributes:

   O: the string "ICANN"."

Out of curiosity, what happens if ICANN is no longer performing the IANA functions contract?

In section 4:

"   This document contains information about an existing service, and has
    no IANA actions."

It seems to me this document is all about IANA actions, specifically the ones that provide the existing service.  I'd have assumed the IANA actions associated with this document would be maintaining and updating the content at the various URLs referenced in the document (in particular, pretty much all of section 3).

Regards,
-drc

On Sep 29, 2010, at 8:47 AM, Joe Abley wrote:

> <Mail Attachment>
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 Sep 2010 16:42:23 +0000

> This strikes me as asking for trouble after the trust anchor is rolled.  I'm not sure we want to codify ephemeral information like a trust anchor in an RFC.

Well, we're not -- we're just codifying the location of historical data. The data itself is codified in the XML file.

If you're suggesting that IANA should attempt to expunge from all places any references to an old trust anchor following a role, I don't think I agree. I think for diagnostic purposes and even just reasons of historical interest an authoritative catalogue of previously-used trust anchors is useful.

> Out of curiosity, what happens if ICANN is no longer performing the IANA functions contract?

Presumably there is always the potential for change. This I-D seeks to document current practice, which is as-described.

> It seems to me this document is all about IANA actions, specifically the ones that provide the existing service.  I'd have assumed the IANA actions associated with this document would be maintainin…

My reading of RFC 5226 was that this section should concern itself with actions that the IANA should take in direct consequence of this document. There are no such actions in this case, which is why I used "no IANA actions".

Joe

---

From: "George Barwood" <[email-masked]>
Date: Thu, 30 Sep 2010 07:45:03 +0100

Joe,

Not directly related to this draft ( it's probably out of scope ), but is there any guidance on the timing of rollover of the Trust Anchor for the Root Zone?

Specifically, how many days/months in advance will a replacement Trust Anchor be published before the old Trust Anchor becomes invalid?

I suggest it may be useful for the community to have some minimum notice figure, to assist in planning.

For example, if I issue an operating system on a disk with an embedded root trust anchor, what is the valid shelf life for the disk?

George

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Sep 2010 09:46:42 +0000

Hi George,

> Not directly related to this draft ( it's probably out of scope ), but is there any guidance on the timing of rollover of the Trust Anchor for the Root Zone?

We have issued no guidance for this to date beyond

(a) in an emergency, a root zone KSK roll-over may happen uncomfortably quickly, depending on the type of emergency;

(b) we don't anticipate a scheduled key roll-over to earlier than 3 years (our messaging as mentioned "3 to 5 years");

(c) the roll-over will follow RFC5011.

Part of the reason (b) is vague is due to (c) -- we don't know how pervasive RFC5011 support is, and we expect RFC5011 support to be important for a large proportion of DNSSEC users. We know that the practical lifetime of software in the field an be long, and so presumably even if RFC5011 was universally shipping in validators today there would still be a necessary delay before we could expect it to be usefully available.

I would certainly expect any scheduled roll-over to be announced (and the trust anchor published) well in advance of the retirement of the old KSK.

We would be happy to hear thoughts from the community on what process and timing makes sense. If the dnsop chairs are happy for that conversation to happen here, we are listening.

Joe

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Thu, 30 Sep 2010 10:51:44 -0600

Hi Joe,

It is not clear if the validUntil time is referring to the time when the
key is expected to be rolled into RFC 5011 revoked state or when it is
expected to be removed from the zone.

What will happen with the keytag field in the published data for an
historical key that has been revoked? Will it still have the original
keyid or keyid+128?

Does it make sense to add an additional timer in the published data so
that the revoked state can be described better?

If RFC5011 rolls are being used, I think the RFC must be referenced.

/S
----------------------------------------------------------------------
Stephan Lagerholm

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Joe Abley
> Sent: Thursday, September 30, 2010 4:47 AM
> To: George Barwood
> Cc: IETF DNSOP WG
> Subject: Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-
> 00.txt
> 
> Hi George,
> 
> > Not directly related to this draft ( it's probably out of scope ),
but
> is there any guidance on the timing of rollover of the Trust Anchor
for
> the Root Zone?
> (a) in an emergency, a root zone KSK roll-over may happen
uncomfortably
> quickly, depending on the type of emergency;
> 
> (b) we don't anticipate a scheduled key roll-over to earlier than 3
years
> (our messaging as mentioned "3 to 5 years");
> 
> Part of the reason (b) is vague is due to (c) -- we don't know how
> pervasive RFC5011 support is, and we expect RFC5011 support to be
> important for a large proportion of DNSSEC users. We know that the
> practical lifetime of software in the field an be long, and so
presumably
> even if RFC5011 was universally shipping in validators today there
would
> still be a necessary delay before we could expect it to be usefully
> available.
> 
> I would certainly expect any scheduled roll-over to be announced (and
the
> trust anchor published) well in advance of the retirement of the old
KSK.
> 
> We would be happy to hear thoughts from the community on what process
and
> timing makes sense. If the dnsop chairs are happy for that
conversation to
> happen here, we are listening.
> 
> 
> Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Sep 2010 16:55:46 +0000

> expected to be removed from the zone.

I see what you mean.

> historical key that has been revoked? Will it still have the original

Good question!

> If RFC5011 rolls are being used, I think the RFC must be referenced.

I think our intention was that the validUntil attribute on the outgoing key would be set as soon as the key was decommissioned, or revoked, or was otherwise not considered a sensible key to use. Since such circumstances would always correspond to the presence of a more current key, this seemed sufficient.

If a client retrieves a trust anchor package and an outgoing anchor is technically still usable (in an RFC5011 roll) but the incoming anchor is also specified, is there any circumstance where we might expect that client to prefer the outgoing anchor?

Joe

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Sep 2010 19:42:05 +0100

I have some high level questions about key rollover.

The problem with RFC 5011 is that software has to have some out-of-band
way to bootstrap its DNSSEC trust anchors. That is, the DNSSEC root KSK is
not a trust anchor, for the purposes of bootstrapping.

At the moment the trust anchors are the ICANN x.509 self-signed
certificate and/or the PGP keyring. What are the processes for rolling
over these keys? How should manufacturers of software or hardware with a
long shelf-life use them to bootstrap DNSSEC?

I think it was a mistake to drop the trust anchor history draft, because
it has a reaasonably coherent answer to the problem. I think the arguments
that it is not secure enough are misguided. What we want is a way for
software to bootstrap its DNSSEC trust anchor that is better than a leap
of faith. This can perhaps be backed up with x.509 validation of the trust
anchor once DNS is up and the higher levels of the stack are able to look
up host names.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Sep 2010 19:04:44 +0000

> anchor once DNS is up and the higher levels of the stack are able to look

I don't follow your logic.

You seem to be saying that trust-history, which uses keys that should not be trusted, is better than using the root-anchor repository, where there are still some open questions.

Isn't the right approach to answer those open questions?

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Sep 2010 12:23:11 -0700

>long shelf-life use them to bootstrap DNSSEC?

When you say "ICANN x.509 self-signed certificate", do you mean the certificate used for the https URLs in this draft? If so, it is not self-signed at all, and in fact is not maintained by ICANN. I think that negates your concern.

>anchor once DNS is up and the higher levels of the stack are able to look

There is *always* a leap of faith, even if it is just "the key that was installed initially". An external third party that is trusted before and after a key rollover is sufficient.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Sep 2010 19:53:06 +0000

> When you say "ICANN x.509 self-signed certificate", do you mean the certificate used for the https URLs in this draft? If so, it is not self-signed at all, and in fact is not maintained by ICANN. I…

I hesitate to speak for Tony, but I presumed he was talking about the CA that was used to sign the CSR, the result being the single CRT that's hosted at <https://data.iana.org/root-anchors/> today.

We are happy to host other CRTs which result from the processing of the same CSR by other Certification Authorities (we've offered to do so multiple times, publicly and privately). No doubt a Certification Authority would have requirements relating to the authenticity of anything they signed, and we're very happy to talk to them about that.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Sep 2010 13:12:46 -0700

>I hesitate to speak for Tony, but I presumed he was talking about the CA that was used to sign the CSR, the result being the single CRT that's hosted at <https://data.iana.org/root-anchors/> today.

Ah, got it. That problem that we have ignored in the PKIX WG for over a decade.

>We are happy to host other CRTs which result from the processing of the same CSR by other Certification Authorities (we've offered to do so multiple times, publicly and privately). No doubt a Certif…

And that solution which folks are forced into. :-)

In all seriousness, if a software vendor / distro wants to have a way to do bootstrapping of the ICANN root over the long term, they should stand up their own CA for this purpose and distribute their own CSR as part of the software. It is nice that ICANN wants to do the distribution for you, but it makes more sense for the software vendor / distro to be the sole trusted third party.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Oct 2010 00:57:51 +0100

> You seem to be saying that trust-history, which uses keys that should not be trusted, is better than using the root-anchor repository, where there are still some open questions.

I am making a distinction between bootstrapping and normal operations. A key that should not be trusted for normal ops may still be useful for bootstrap.

The threat we are trying to deal with is a combination of a root KSK compromise and widespread attacks on software that is bootstrapping its DNS trust anchor. (Happily the first is unlikely and the second is a narrow target.)

With trust anchor history in the DNS, a validator can start from a stale trust anchor, confirm that it is stale, update it to a provisional trust anchor, start its DNSSEC service, use the working DNS layer to obtain additional signatures that affirm that the provisional trust anchor is in fact OK, then make the service available to other users.

Without trust anchor history, you start off with a trust anchor that is broken, and the only option is to downgrade to insecure DNS and use that to get the new trust anchor and its signatures.

It seems to me that keeping the trust anchor history in the DNS should make it possible to reduce the attack window a lot. This is particularly true if the history zone has a short delegation chain from the root, to minimise the number of insecure queries a bootstrapping validator must make.

> Isn't the right approach to answer those open questions?

I think the answer requires a solution to exactly the same problem, except the keys and signatures are at higher levels in the protocol stack. How does a bootstrapping device deal with a rollover of the IANA web server's certificate's CA? Or of the special CA that IANA uses to sign the root KSK?

The policies and procedures for managing the root zone keys are well documented and performed in the open. It is all very impressive. If you want bootstrapping to be as convincingly secure, you are going to have to duplicate all this ceremonial for the higher level keys. This seems redundant to me.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Oct 2010 01:10:46 +0100

On 30 Sep 2010, at 20:23, Paul Hoffman <[email-masked]> wrote:
> 
> When you say "ICANN x.509 self-signed certificate", do you mean the certificate used for the https URLs in this draft?

No: see http://data.iana.org/root-anchors/icannbundle.pem and http://data.iana.org/root-anchors/Kjqmt7v.crt

> There is *always* a leap of faith, even if it is just "the key that was installed initially". An external third party that is trusted before and after a key rollover is sufficient.

I am assuming that the key that was installed initially was validated manually, so that is not a leap of faith. The problem is that a missed rollover causes a break in the chain of trust. We want to retain as much trust as possible without requiring a manual validation every time old software is installed or whenever you do a factory reset on hardware with an embedded validator.

You can't invoke a magic trusted third party because they also have to roll their keys. You have moved the problem without solving it.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Oct 2010 01:22:38 +0100

> In all seriousness, if a software vendor / distro wants to have a way to do bootstrapping of the ICANN root over the long term, they should stand up their own CA for this purpose and distribute the…

Yes, that is what vendors will have to do given the tools we have provided them so far.

The problem is that this commits them to providing an online service that will last for the lifetime of their software or equipment. For consumer gear this will be long enough to cover at least one rollover. If they don't or can't maintain the service, a rollover will brick any equipment that is off at the time, or which is restored to factory settings after a rollover, etc.

I think we should be able to make it more robust.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Sep 2010 17:29:43 -0700

>Without trust anchor history, you start off with a trust anchor that is broken, and the only option is to downgrade to insecure DNS and use that to get the new trust anchor and its signatures.

True, but the new trust anchor you get can be validated by some other source. For example, it could be signed by the key of the vendor of whichever software is doing the getting, or by a trusted third party.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Oct 2010 07:58:19 +0100

What is the purpose of the historical information in the XML TA file?

Tony.