Subject: [DNSOP] draft-jabley-dnsop-validator-bootstrap-00

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 14:32:53 -0500

Hi all,

Per below, Dave and I scribbled some thoughts down about how we might recommend validators obtain a useful root zone trust anchor on startup.

It's scrappy, and it's little more than I have said on this list in the past week, but I thought it might be handy to have in written form. I used a dnsop tag rather than a dnsext one at Andrew Sullivan's suggestion, since this looks like operations more than it looks like protocol work.

dnsoppers: there's a party going on in dnsext. Look over the fence for context.

Reply-To set.

Joe

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 31 January 2011 14:24:56 EST
> To: Joe Abley <[email-masked]>
> Cc: Dave Knight <[email-masked]>
> Subject: New Version Notification for draft-jabley-dnsop-validator-bootstrap-00 
> 
> 
> A new version of I-D, draft-jabley-dnsop-validator-bootstrap-00.txt has been successfully submitted by Joe Abley and posted to the IETF repository.
> 
> Filename:	 draft-jabley-dnsop-validator-bootstrap
> Revision:	 00
> Title:		 Establishing an Appropriate Root Zone DNSSEC Trust Anchor at Startup
> Creation_date:	 2011-01-31
> WG ID:		 Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> Domain Name System Security Extensions (DNSSEC) allow cryptographic
> signatures to be used to validate responses received from the Domain
> Name System (DNS).  A DNS client which validates such signatures is
> known as a validator.
> 
> The choice of appropriate root zone trust anchor for a validator is
> expected to vary over time as the corresponding cryptographic keys
> used in DNSSEC are changed.
> 
> This document provides guidance on how validators might determine an
> appropriate trust anchor for the root zone to use at start-up, or
> when other mechanisms intended to allow key rollover to be tolerated
> gracefully are not available.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jan 2011 15:26:27 -0500

On Jan 31, 2011, at 2:32 PM, Joe Abley wrote:
> It's scrappy, and it's little more than I have said on this list in the past week, but I thought it might be handy to have in written form.

I'm not entirely sure I grokked section 6.   It sounds like you're proposing that we use locally-configured X.509 certs from certificate authorities as the only mechanism for validating the trust anchor that we retrieve from the IANA.

---

From: John Bashinski <[email-masked]>
Date: Mon, 31 Jan 2011 16:44:12 -0500

On 2011-01-31 14:32, Joe Abley wrote:

> Per below, Dave and I scribbled some thoughts down about how we might
> recommend validators obtain a useful root zone trust anchor on
> startup.

Wow, that's fast service. :-)

> Individual trust anchors are also packaged as X.509 identity
> certificates, signed by various Certificate Authorities (CAs).

How firmly are you attached to your approach? Would you be prepared to
consider supporting alternatives, if consensus could be gathered behind
them?

If so, what would be your concerns? We've heard a lot about my/our
requirements. What are *your* requirements? What would an alternative
bootstrap scheme have to do before you could support it? What procedural
guarantees can you provide, and what guarantees can't you provide?

From what I'm seeing, I kind of doubt we'll get consensus on anything
else quickly enough to be useful on our timetable, so I *suspect* we're
going to have to do what you suggest, at least until something better
comes along, and maybe forever. For the longer term, maybe we could
think about other things.

Given our own constraints, under your draft we (Cisco) would need to
maintain our own bootstrapping service. Specifically, we'd need to play
the role of the X.509 CA signing the root KSKs in your section 5.3:

> Individual trust anchors are also packaged as X.509 identity
> certificates, signed by various Certificate Authorities (CAs).

If we do have to roll our own as you suggest, we may want to give
customers more assurance than your draft specifies, by augmenting your
procedure.

Specifically, we might do as you suggest, but *additionally* retrieve
from Cisco a signed 5011 rollover list.  The idea there would be that
somebody would have to compromise *both* Cisco and at least one
historical root KSK. Of course, the downside would be that any non-5011
key roll would break the devices.  We'll probably have to think about
that. Of course, it's even less likely that you'd want to suggest it to
others than that we'd do it ourselves.

Prodedural details
==================
I assume you *are* saying that the

  http://data.iana.org/root-anchors/root-anchors.xml

URL is guaranteed good for a long time?

I'm not sure what procedure we're meant to use to get the validated CSRs
to create the X.509 certificates for new KSKs. Can you say anything
about that?

I assume that the "ultimate" way to do it is to send some people to a
key ceremony. To be honest, I'm not sure that I could convince
management (or even myself) that that gave enough extra assurance to be
worth it.  I suspect what we'd end up doing, absent other guidance,
would be just grabbing the CSR from wherever, and looking at the root
KSK in use on our own internal systems to see if it was right... then
signing it.

Some comments on the draft itself:

Finding CAs
===========
You say:

> URLs
> to allow those certificates to be retrieved are included as optional
> elements in the XML document.

I don't actually see any CA URLs in the XML at the moment.

Obviously you can't just grab a root cert from such a URL and trust
it, anyway... you have to have either a wired-in copy of the cert
itself, or at least a wired-in copy of its public key. So I'm
not sure I see what having the URLs in the XML would do for anybody.

> alternatively a vendor may instantiate its own CA and make
> arrangements with the root zone KSK manager to have the corresponding
> identity certificate locations published in root-anchors.xml.

Our devices already have copies of our own CA's root cert for other
reasons, so we'd just let them rely on that. I'd assume others would
do similarly.

Time
====

> 3.1 Initial State
> [...]
> A validator must confirm that its local clock is sufficiently
> accurate before trust anchors can be established, and before
> processing of DNSSEC signatures can proceed.  Discussion of timing
> considerations can be found in Section 4.

How?

I know I brought it up, but I'm getting a little nervous about using the
home router as the only reference point. Nonetheless, it's a good
paradigmatic case, and I'll go with it for now. You're a home
router. You've just been plugged in, either new from the box or after
being in a closet for a long time. Do you:

1. Rely on your local real-time clock? I'm not saying this is impossible,
   but:

   a. Much existing hardware (not just Linksys; many home routers)
      doesn't have RTCs. Putting one in would significantly increase the
      build cost of the hardware, I'm guessing by several percent.
      And it would reduce the reliability and shelf life.

   b. If you've been in a closet for a while, your RTC may have drifted
      enough to matter. Perhaps more likely, the battery for your
      RTC may have died... an event you may or may not be able to detect
      and usually can't report.

   c. The user may have set the RTC wrong before you went into that
      closet. This is perhaps more likely for a PC than for a router,
      but it could happen... and PCs are also in scope.

2. Rely on NTP? If so, then:

   a. How do you know which NTP sources to trust?
   b. How do you set up authentication with them?

   Public NTP is unauthenticated, and if I remember correctly it's not
   *possible* to authenticate NTP in a public network. The public-key
   stuff is used to distribute shared keys. I could be wrong; it's
   been a while. But that's how I remember it. Anyway, you'd need some
   kind of NTP trust anchor... which puts us back where we started.

3. GPS? WWVB (or non-US equivalent)? Can't receive either one where my
   router is, even if it had the hardware. And both are jammable. WWVB,
   at least, is easily falsified, as are the similar but incompatible
   systems in use in various places outside North America... those where
   such systems exists, that is. I haven't looked into GPS, but I suspect
   it's spoofable too.

4. Make the user enter the time? How does the user know she needs to
   do that?

   For us, another question is how we keep the user from buying the
   competitor's box that doesn't do DNSSEC and doesn't ask for the
   time. Users see all this stuff as a hassle. I was told today
   that even entering a PIN to get WiFi up causes a noticeable number
   of products to go back to the store.

The state of the art in enterprise networks is *unauthenticated* NTP
with internal hosts. The state of the art in consumer is unauthenticated
NTP with a pool on the public Internet.

This is a huge problem for us with bootstrapping all kinds of crypto
protocols, actually, not just DNSSEC. There's this pervasive assumption
that the time of day is not only known, but known with such certainty
that it can be trusted to ensure the security of systems that are
otherwise engineered to take CPU-aeons to compromise. The problem is
that it's just not an assumption we know how to meet.

In a lot of cases, we just end up having to assume that keys are valid
from the beginning of time to the end of time. I'd very much like to not
have that be true, but I don't know how to fix it.

I could imagine a distributed system of digital notaries and time
stampers that at least let you establish that it was "no earlier than"
some particular time, and that also gave you some assurance that some
set of past events had happened in a particular sequence and within
particular time parameters. You could build that with mutually
distrustful "authorities", and use a quorum or something to prevent any
one of them from messing it up. I think that sort of thing is (part of)
what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy
it sanely in time to be useful for this application... and I don't
think you can build *anything* that lets you detect lies about the
time if an attacker controls *all* your communications.

Trust
=====
I'm not sure I understand the phrase "trust anchor" the same way you
do.

> 5.1 Retrieval of Trust Anchors from Local Sources
>
> A trust anchor which is packaged with validator software can never be
> trusted, [...]
> 
> Validators should never use local trust anchors for bootstrapping.

I think that by "trust anchor" here, you really mean "DNSSEC root
KSK", because below you say:

> 5.3 Retrieval of Trust Anchors from the Root Zone KSK Manager
> [...]
>
>  3. Retrieve the corresponding X.509 identity certificates for the
>     key identified in the previous step, for use in establishing
>     trust in the retrieved trust anchor (see Section 6).
> [...]
> 6. Establishing Trust in Candidate Trust Anchors
> 
> Once a candidate trust anchor has been retrieved, the validator must
> establish that it is authentic before it can be used.  This document
> recommends that this be carried out by checking the signatures on
> each of the X.509 identity certificates retrieved in the previous
> step until a certificate is found which matches a CA trust anchor
>
> This verification phase requires that validators ship with a useful
> set of CA trust anchors, and that corresponding identity certificates
> are published by the root zone KSK manager.

Either way, it's a local trust anchor... and I don't see why X.509
keys are any less compromisable than DNS keys...

					-- jbash

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 17:14:42 -0500

[we should probably choose either dnsop or dnsext for this, and stop posting to both, sorry for starting that trend]

> consider supporting alternatives, if consensus could be gathered behind

Publishing the trust anchor as a CSR and subsequently signing that to produce a certificate is part of the existing workflow for KSK ceremonies, and changing it will not happen quickly. Change is certainly possible, however.

My hope with this document was to present it in Prague, and suggest that the (a) working group adopt it. I think the general subject area needs work, and I think a working group is likely to do a better job than a pair of individuals.

I don't think anybody is married to any particular approach.

> Prodedural details

It's specified in the KSK manager's DNSSEC Practice Statement, and the IANA people at ICANN are happy to support it for as long as we manage the key.

> to create the X.509 certificates for new KSKs. Can you say anything

We (IANA, again) expect to find a workflow that suits the CA in question. If that means that IANA staff provide attestations and a copy of the CSR in a tamper-evident bag with corresponding documentation for a chain of custody, we can do that.

> KSK in use on our own internal systems to see if it was right... then

The participants who attended the first ceremony were able to witness the generation of the key and the corresponding hash on a screen connected directly to the ceremony laptop. Subsequent ceremonies have principally been concerned with processing the set of key material supplied by VeriSign for the next quarter, and have not involved key generation.

> Some comments on the draft itself:

Right, this is something that occurred to me as we were discussing the bootstrap problem. I have a rev to the trust anchor document ready to go that includes those optional elements.

> not sure I see what having the URLs in the XML would do for anybody.

The certificates you pull from those URLs would be of the form

  http://data.iana.org/root-anchors/Kxxxxxx.crt
    (the current name for the certificate produced using the IANA CA)
  http://data.iana.org/root-anchors/Kxxxxxx.crt.cisco
    (if that's the kind of thing cisco decided to do)
  http://data.iana.org/root-anchors/Kxxxxxx.crt.some-commercial-CA
    (and so on)

The idea of inserting optional elements into the XML schema was to allow a device parsing root-anchors.xml to enumerate a list of URLs for candidate certificates.

Whether or not you decided to trust that certificate would depend on whether you had shipped with an appropriate CA trust anchor (e.g. the IANA one, or a cisco one, or the some-commercial-CA one).

> reasons, so we'd just let them rely on that. I'd assume others would

Then perhaps this scheme is not as unwieldy for cisco as it might first have seemed -- if that cisco CA key can be exercised to process the CSR containing the root zone KSK public key, and we can publish that in a reasonable place, the extra process involved might be fairly small.

>> considerations can be found in Section 4.

Good question. The fact that the answer is not obvious doesn't eliminate the requirement to set the local clock, though.

> KSK", because below you say:

Yes, I mean a copy of the root zone KSK public key, or a hash of it.

> keys are any less compromisable than DNS keys...

The difference is that X.509 keys, as deployed by CAs, have expected lifetimes measured in decades. Right now we don't know what the expected lifetime of the root zone KSK is.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 19:40:35 -0500

On Mon, Jan 31, 2011 at 5:14 PM, Joe Abley <[email-masked]> wrote:

> The difference is that X.509 keys, as deployed by CAs, have expected
> lifetimes measured in decades. Right now we don't know what the expected
> lifetime of the root zone KSK is.
>

To be precise here, there is no difference in the likelihood that the keys
will be compromised.

The difference is that the X.509 protocol is designed to support keys that
are persistent over long periods (decades) and DNSSEC is not.

In particular an X.509 self-signed certificate is an assertion that the key
holder will maintain and use the associated private key in accordance with
the specified practices for the specified length of time.

You can easily find out how long Comodo or Symantec or whoever is going to
maintain their SSL CA roots, the information is right there in the cert
store and is irrevocable in that the CA can extend the time period (through
recertification) but cannot reduce it.

My advice to Cisco would be to use their existing root to sign the published
CSR for the DNS root KSK in the short term at least.

In the longer term we are going to have to have a look at the problem at a
higher level and work out how we are going to solve it in a scalable way
across all the platforms that involve a root key.

We are starting to make quite a little collection of industry forums that
are doing this root key management as a sideline.

-- 
Website: http://hallambaker.com/

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 20:53:47 -0500

> I'm not entirely sure I grokked section 6.   It sounds like you're proposing that we use locally-configured X.509 certs from certificate authorities as the only mechanism for validating the trust a…

The problem I was trying to find a solution for was how an unattended validator with default configuration that nobody is ever going to change, and which might sit on the shelf for a year before it is plugged in, can find a useful trust anchor for the root zone.

ICANN has made no promises about the longevity of either the PGP key or the certificate used to generate the S/MIME signature over the root-anchors.xml file, so that's not necessarily the right answer.

Using signatures from established X.509 CAs whose policy and practice statements confirm their intention for keys to be long lived seems like a solution that would work, more or less with what is published today, and that's what we wrote up. It also doesn't depend on a single key; if a variety of certificates were available (as opposed to the single certificate from the IANA CA today) there is operational recourse to events such as CA failure/compromise that doesn't involve truck-roll.

For some platforms using a SysTrust-accredited CA trust anchor seems like it comes for free, since the operating system vendor already maintains that list as part of its regular software update process.

No doubt there are other answers.

Joe