Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00

[John Bashinski <[e-mail]>]

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