[Last-Call] Re: [Ntp] draft-ietf-ntp-roughtime-15 ietf last call Genart review

[Hal Murray <[e-mail]>]

[I'm answering your questions, not commenting on the text in the draft.]

> I think this needs some clarification. Because, AFAIK NTP and NTS does
> not require the client to have prior knowledge of the time either, right?

NTP works fine without any prior knowledge of time.  It is not secure.

NTS uses TLS.  TLS uses certificates.  Certificates have not-before and 
not-after times.

NTS as currently deployed piggybacks on the web certificate 
infrastructure.  Standard software update procedres keep the root 
certificates up to date.

Certificates from Lets Encrypt have 90 day lifetimes.  I think you get a 
year or two if you pay for certificates.  I've heard that there is work to 
reduce lifetimes.  I'm not familiar with the details.  I think the idea is 
to automate updating certificates so updating one is not a hassle, then we 
can phase in shorter lifetimes which will reduce the damage if a private 
key gets compromised.

My nasty case for getting time without any prior knowledge of time is a 
spare gizmo that has been sitting on the shelf for a dozen years.

NTS could get started without knowing time if we use self signed certificates with a long lifetime.  But then we have to distribute their public keys.  (as well as run long lifetime servers.)


Roughtime has long lifetime keys.  If it gets packaged cleanly, people using NTS won't have to worry about getting started without knowing the time and people running NTS servers won't have to worry about self signed certificates.


Note that in addition to long lifetime keys/certificates, you also need long lifetime IP Addresses.  DNSSEC needs time.

---------


> Why does the protocol only allow to obtain a rough idea of the current
> time, instead of a more precise time? 

Because good time isn't needed and if you don't promise good time you don't have to spend any effort discussing how good it is or trying to make it better.

---------

> It does provide proof that the response was issued after the server
> received the request, but AFAIU it does not provide any proof regarding
> when the timestamp was issued. 

The timestamp came from the server.  You have to trust the server.
(If not, why are you using it?)



-- 
These are my opinions.  I hate spam.