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

Paul Wouters <paul@xelerance.com> Tue, 01 February 2011 07:27 UTC

Return-Path: <paul@xelerance.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC13B3A6A79; Mon, 31 Jan 2011 23:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlOarnU8Rp7a; Mon, 31 Jan 2011 23:27:04 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E4C693A68BD; Mon, 31 Jan 2011 23:27:03 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6096AC4FE; Tue, 1 Feb 2011 02:30:18 -0500 (EST)
Date: Tue, 1 Feb 2011 02:30:17 -0500 (EST)
From: Paul Wouters <paul@xelerance.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
In-Reply-To: <AANLkTikxd+ODmWoyeNLvPs1R2VD2EcFNrdAX=8oWuCX6@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.1102010220360.4802@newtla.xelerance.com>
References: <AANLkTikxd+ODmWoyeNLvPs1R2VD2EcFNrdAX=8oWuCX6@mail.gmail.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Knight Dave <dave.knight@icann.org>, dnsext List <dnsext@ietf.org>
Subject: Re: [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 07:27:05 -0000

On Tue, 1 Feb 2011, Brian Dickson wrote:

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

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.

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

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