Subject: [DNSOP] Time vs bootstrap (was Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00)

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Feb 2011 01:44:40 -0400

Top-replying here, to attempt a high-level suggestion on how to get
some close approximation of time, using DNS/DNSSEC exclusively.

(Warning to those with weak stomachs - this is mildly evil stuff.)

First, without any assurances on the accuracy of local time, the best
that can be achieved regarding bootstrap-to-trust-anchor is
consistency validation.
Having multiple ways to validate the consistency of answers received
over DNSSEC, can create a high degree of confidence in the validity of
the root key, but cannot get to 100% (I don't think, anyway).

However, once you have a trust anchor (root key) that you have a lot
of confidence in, you can then do some cute DNSSEC tricks to get a
rough idea of time, and then a better idea of time.

First, look at the contents of the RRSIGs for the root. If you believe
the RRSIGs, you also necessarily believe that the current time must be
within the start/end time of those RRSIGs.

That might not be close enough for your needs, but may be enough to
further validate the root key. (If it is, validate it before
continuing.)

Next, consider what needs to happen for TLDs that update very frequently.
When they update, their SOA SN needs to change.
And, if they are signed zones, the SOA record's RRSIG needs to be
generated when this happens.
Using the start date/time of such an RRSIG on the SOA for such a zone,
should give a pretty good value for the current time, to at least an
accuracy of a couple of minutes.
This may be good enough for DNSSEC purposes.

(If you do use RRSIG timestamps, be sure to validate the RRSIG first
before trusting the values on the timestamp!!!)

While horribly kludgey and mildly evil, it does get an answer that is
reasonably trustworthy, moderately accurate/precise, and only uses
DNSSEC.

(It borrows the main idea from using GPS for clock as well as position.)

Brian

On Mon, Jan 31, 2011 at 5:44 PM, John Bashinski <[email-masked]> 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.
>
>
> 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.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Feb 2011 02:30:17 -0500 (EST)

> within the start/end time of those RRSIGs.

But if the rootkey was compromised, so would the RRSIGs? At least for the
view of the device - if the attacker cannot fool the client that the old
compromised root key is the real one, or preset a fake successor in some
history zone, then the attacker lost anyway.

> accuracy of a couple of minutes.

That actually is a nice trick. Though I don't think it gets you acuracy on
the minute, but hours surely. org. got me witin an hour, gov. within 3 hours.

> This may be good enough for DNSSEC purposes.

At least to then do ntp and and see that it matches our rough expectation.
Though in all, if the attacker is your controlling upstream, you are lost.

Paul