From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A332121F1D6 for ; Sun, 23 Mar 2014 05:22:31 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h18so5575396igc.2 for ; Sun, 23 Mar 2014 05:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kig8AEi3g5mXxSdrS8Ig6iltYXGv2eaP558H8oQ28OQ=; b=aOGn0FgGUqb5I0Wnu7fcMHNsHB8N0Md3bxd2LeAwv+g4oeiNUxD5I8xVRN/UDTdzL7 XWoV2V0TgmE6/wuYAfL6APpM6Veg3VYa9Et/BlvwPAdZ4UWLcuws1Wqg3FP8WFWz91mb L/O4bOhLbte6sVrffGKLv668yEnBn9Wf84eJ4eAtIwKRsQhoCq2AILwGk4f12Lr9GBbd dcoytX5RFCk+7J+IheoUd00y4IV2PQ0tBv3FML3+qVsgW4MgqxCwtWvWh/7AaRJR4Gg2 Ee+oGPzuQIaGr00MKMGfWVuSybcDgb1DinpwlqYn5XluAvM9BpiRcshNZhegAflXfYtQ OmxA== MIME-Version: 1.0 X-Received: by 10.50.111.79 with SMTP id ig15mr6730425igb.14.1395577350652; Sun, 23 Mar 2014 05:22:30 -0700 (PDT) Received: by 10.64.238.70 with HTTP; Sun, 23 Mar 2014 05:22:30 -0700 (PDT) In-Reply-To: <8738i9rwrx.fsf@alrua-x1.karlstad.toke.dk> References: <8738i9rwrx.fsf@alrua-x1.karlstad.toke.dk> Date: Sun, 23 Mar 2014 13:22:30 +0100 Message-ID: From: Aaron Wood To: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= Content-Type: multipart/alternative; boundary=089e01294c8c3e0b8504f5452cc3 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 12:22:33 -0000 --089e01294c8c3e0b8504f5452cc3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Mar 23, 2014 at 12:15 PM, Toke H=F8iland-J=F8rgensen = wrote: > Aaron Wood writes: > > > or we find a way to have long-lived dnssec entries. > > Is the timing controllable somehow? I.e. would it be possible to set up > a special domain name with a really long-lived key that could be queried > indefinitely for the IP address of one or more NTP servers, even in the > face of an a wrong clock? My understanding (albeit, not a deep one) is that the dnssec keys all have a fairly short expiration, just a few months. It would be nice if they were longer-lived (in this particular case), but you still have an issue of needing to decide what time is "now", within a reasonable degree, in order to validate the domain. Alternatively, you assume that you don't care about the timeliness of the entry, for the resolution of ntp server names, and then you have to somehow convey to the resolver that you want a secure lookup, but it's ok if it's expired (or too new, or...), which gets back to some of the earlier parts of this discussion. -Aaron --089e01294c8c3e0b8504f5452cc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 23, 2014 at 12:15 PM, Toke H=F8iland-J=F8rgensen = <toke@toke.dk><= /span> wrote:
Aaron Wood <woody77@gmail.com> writes:

> or we find a way to have long-lived dnssec entries.

Is the timing controllable somehow? I.e. would it be possible to set = up
a special domain name with a really long-lived key that could be queried indefinitely for the IP address of one or more NTP servers, even in the
face of an a wrong clock?

My understanding = (albeit, not a deep one) is that the dnssec keys all have a fairly short ex= piration, just a few months. =A0It would be nice if they were longer-lived = (in this particular case), but you still have an issue of needing to decide= what time is "now", within a reasonable degree, in order to vali= date the domain. =A0Alternatively, you assume that you don't care about= the timeliness of the entry, for the resolution of ntp server names, and t= hen you have to somehow convey to the resolver that you want a secure looku= p, but it's ok if it's expired (or too new, or...), which gets back= to some of the earlier parts of this discussion.

-Aaron
--089e01294c8c3e0b8504f5452cc3--