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

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 01 February 2011 05:41 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8D80A3A6B72; Mon, 31 Jan 2011 21:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.261
X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id YSkd2anvB5Zy; Mon, 31 Jan 2011 21:41:26 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id 9DEC93A6B68; Mon, 31 Jan 2011 21:41:25 -0800 (PST)
Received: by fxm9 with SMTP id 9so7019419fxm.31 for <multiple recipients>; Mon, 31 Jan 2011 21:44:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=zyysIuI4bM+0IsoztmRh0PMHZx1PAsRDLEmvAMa64ls=; b=VXzh0+NbGA0j8l31zkUJKTCMNpsYRWFKsbngzxzM/KSsxNadTUXCj/hP8sCXrJvAdH VehqMVZ0gai/tsvnuwyAZbjBQTiads5TEPBDa1Rr1C+MJkqMKpk7shHUG57KRyuI87E4 islK6tl1X46GWGoyJUr8UfuL7yOnly3s4OQI4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rU8ggN0nmr499Zgcb14wyckRXMdzKDYmN0U4xkrSNPAwTi/PADwQH5YppHaFTeqluU LKJgKnolPxqSWcD0evGzsc93fLHFq9sob+U6rrXhJSI15UXVepJIJ1iLGWZUPttX2eg6 80LwSxBUPIevHqUnJNHRgvD3J5c6B1lVQ44pM=
MIME-Version: 1.0
Received: by with SMTP id g2mr2370592fal.75.1296539080116; Mon, 31 Jan 2011 21:44:40 -0800 (PST)
Received: by with HTTP; Mon, 31 Jan 2011 21:44:40 -0800 (PST)
Date: Tue, 01 Feb 2011 01:44:40 -0400
Message-ID: <AANLkTikxd+ODmWoyeNLvPs1R2VD2EcFNrdAX=8oWuCX6@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: John Bashinski <jbash@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 31 Jan 2011 21:45:43 -0800
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, dnsext List <dnsext@ietf.org>, Knight Dave <dave.knight@icann.org>
Subject: [DNSOP] Time vs bootstrap (was Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 05:41:27 -0000

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

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

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


On Mon, Jan 31, 2011 at 5:44 PM, John Bashinski <jbash@cisco.com> 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.