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

[Danny Mayer <[e-mail]>]

Hi John,

I just saw this, so sorry for the late response. See inline for comments.

Danny

On 1/31/2011 4:44 PM, John Bashinski wrote:
> On 2011-01-31 14:32, Joe Abley wrote:
> 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.
> 

While generally people are not doing authentication publicly there is no
reason why they cannot do do. NTP Autokey has been around for a long
time, probably about 15 years, the latest RFC is RFC5906. The one
problem you have is that you need to provision a key, OOB, to be able to
authenticate the server and you will have to know what servers to point
to to get the NTP packets. If you cannot enter FQDN's, because the
servers being pointed to may change addresses and you cannot yet look
them up as DNS is not available to you, then you are forced to use IP
addresses. The good news is that NTP does not require that initially
your local time have a valid time as long it's within 68 years. If your
device clock doesn't have an RTC you could always set it initially to
the build date and then have NTP set it from there.

> 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.
> 

That would imply that you have an antenna connected to your router. On a
home router I don't think so and there are some places that couldn't
even receive a signal even if it did.

> 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.
> 

No, state of the art is authenticated NTP. The state of operational art
is unauthenticated NTP.

> 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.
> 

Autokey is one of those which requires a key provided out-of-band on the
device just to be able to authenticate the servers and you may need one
for each server. Autokey is unique in that it is not an accurate
time-dependent authentication protocol for obvious reasons.

> 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.

If you use NTP for accurate time you should provision a minimum of 3 NTP
servers to point to and generally 4. In your specific situation I'd
recommend 5.

Danny