Re: [dhcwg] [ntpwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 02 December 2013 14:30 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D44B1AE49A for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 06:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUDsEGGtBZHr for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 06:30:03 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52B1AE498 for <dhcwg@ietf.org>; Mon, 2 Dec 2013 06:30:03 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C6B1C20168; Mon, 2 Dec 2013 10:43:10 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 2733E63B88; Mon, 2 Dec 2013 09:29:55 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 16E7563AEF; Mon, 2 Dec 2013 09:29:55 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: NTP Working Group <ntpwg@lists.ntp.org>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>
In-Reply-To: <529C1A31.2080900@ntp.org>
References: <20131202044734.B78E0406060@ip-64-139-1-69.sjc.megapath.net> <529C1A31.2080900@ntp.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 02 Dec 2013 09:29:55 -0500
Message-ID: <25552.1385994595@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [dhcwg] [ntpwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 14:30:05 -0000

    > On 12/1/2013 11:47 PM, Hal Murray wrote:
    >> Does DNS using DNSSEC return a specific error code for time-invalid?
    >> Or just a generic didn't-work?
    >> 
    >> How close does the time have to be for DNSSEC to work?

Sadly, DNSEXT did not (despite repeatedly trying to socialize this idea a
decade ago) give anything other than SERVERR when things fail.  That isn't to
say that it can be done, but there is no standard way to do this.

Time SHOULD be within 1 hour, but in practice, records are signed with
30-day periods, so as long as you aren't in error across that boundary, 
you could be 12 or even 24 hours off.  

Having your time in the past (trying to validate things in the future) is
likely the more common case -- it's also likely the less vulnerable
situation, as if someone is going to replay old data, they are likely going
to replay it from the real past, not, the future :-)

Many suggest to turn off time validation when a CPE router boots up until it
can validate enough DNS to get time records --- if one runs the DNSSEC for
the NTP server well, then the records will validate for years at a time.
If the CPE touches a file after getting valid time after booting, then the
CPE won't be back in 1970, it will know the time is at least as recent as
when it last validated time via DNSSEC-secured NTP.

Danny Mayer <mayer@ntp.org> wrote:
    > That's a question that should be asked in the dnsext WG mailing list
    > (though technically the Working Group is now closed). Olafur and I
    > (apart from Ted who is IETF area director) are probably the only ones
    > on these lists who participate in that mailing list. Olafur was one of
    > the cochairs of the DNS ext working group.

I have done all of the above.

    > The proposal seems to suggest that a timestamp in 64-bit time_t be
    > distributed by DHCP. I'm not sure why not a NTP timestamp instead.

I agree.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [