ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

2013-10-09 13:12:00
On Oct 9, 2013, at 1:59 PM, Joe Abley <jabley(_at_)hopcount(_dot_)ca> wrote:
DNSSEC validation imposes a requirement for clock sync (to the accuracy 
reasonably required to consider signature inception and expiry times). There 
is a possible future in which such validation takes place on end hosts, 
rather than intermediate resolvers. (We may wind up somewhere else, but there 
are certainly people who think that is the Right Way).

Sure.   Including me.

In that sense any device that needs to look up names in the DNS has a 
potential requirement for time sync.

Yes, definitely.

Of course even the wall clock you imagine might have a vendor who is capable 
of running their own array of time servers as (e.g.) Apple does, but it seems 
reasonable to imagine that there will be people who are not in that position, 
and since I agree with you when you say:

Of course, if a CPE vendor were to hard-code the FQDN of an NTP server 
belonging to someone else into their devices, that would be disastrous.

it seems to me that there's a plausible use case for a DHCP client to receive 
direction on what servers to chime against.

Yup.   There's an equally plausible use case for distributing DNSSEC root keys 
using DHCP, so that the DHCP client has a current copy of the keys.   This 
totally solves the key rollover problem!

:)

Of course, the situations are not precisely analogous, but the point is that 
just because DHCP could be conveniently used to suit some purpose, does not 
mean that it _should_ be used to suit that purpose.  I think reasonable people 
can differ about configuring NTP over DHCP, but it really does depend on how 
you are using NTP.   I think the main justification for using DHCP to configure 
NTP is in fact that it is expedient, even though it's not secure.


<Prev in Thread] Current Thread [Next in Thread>