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

Ted Lemon <> Sun, 01 December 2013 21:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA0FE1AE16D for <>; Sun, 1 Dec 2013 13:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZwCuQ1Lc55s6 for <>; Sun, 1 Dec 2013 13:18:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 980AC1ADF69 for <>; Sun, 1 Dec 2013 13:18:13 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Sun, 01 Dec 2013 13:18:11 PST
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 7C09F1B8244 for <>; Sun, 1 Dec 2013 13:18:11 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 58A94190043; Sun, 1 Dec 2013 13:18:11 -0800 (PST)
Received: from [] ( by CAS-01.WIN.NOMINUM.COM ( with Microsoft SMTP Server (TLS) id; Sun, 1 Dec 2013 13:18:11 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Sun, 1 Dec 2013 16:18:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <>
To: Olafur Gudmundsson <>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: []
Cc: " WG" <>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Dec 2013 21:18:15 -0000

On Dec 1, 2013, at 3:53 PM, Olafur Gudmundsson <> wrote:
> I wrote up this short document in order to address a problem seen in certain devices
> that do not have good time at startup. The document  proposes a DHCv4 option and
> DHCPv6 option to supply current time to a device. (there is also a proposed ND option
> for the same thing). 
> I looked into using option 152 from Bulk Query but that is only 32 bit long, and 
> it seems cleaner to just get a 64bit time_t option into DHC

I think it's worth thinking about the threat model this addresses, and the threats to which it exposes clients.   The threat model it addresses is the one where ancient DNSSEC responses are replayed in order to fool the client with stale information that would fail to validate (right?).

The problem is that the trust model for DHCP doesn't provide any assurance that the time being provided by DHCP will be any more trustworthy, even if the DHCP message is authenticated using the new proposal for doing public-key authentication of DHCP messages.  This authentication model typically depends on a leap of faith or else a pre-shared public key.   In the latter case, the time could be considered reasonably trustworthy.   In the former case, there's no reason at all to consider it trustworthy—if the DNS server on the network is going to attack you, so is the DHCP server.

Hm, okay.   The one thing I can see this protecting against is the case of a rogue DNS server attempting to slam responses at a client on an otherwise-trustworthy wire.   But this is a really hard attack—it has to have stored an old signed DNS hierarchy with stale keys that have been compromised.   This seems like it would be a fairly difficult achievement—to present a consistent out-of-date hierarchy, the rogue server would have to have or get answers to any conceivable query that could be made against it, and be able to produce them faster than the real DNS server.   Even if it has a copy of an old root key, this is a tall order, and furthermore depends on the client resolver not having a more recent root key, which could be used to disprove the attacker's assertion that an old key is current.   It seems like SAVI would be a better way to prevent this attack.

What am I missing here?

(None of this is to say that a time option is necessarily a bad idea—I'm just not convinced that it addresses a plausible threat model.)