[Ntp] draft-ietf-ntp-roughtime-05: general comments

[Christer Weinigel <[e-mail]>]

Hi all,

sorry for being late with comments, but I've been kind of busy with 
moving and renovating lately.

Anyway, I've tried to read up on roughtime a bit and have a few general 
comments on the draft.

Since I usually work with embedded programming on small systems, many of 
these comments are made with the embedded systems programmer hat on.  To 
begin with, I like that it seems to be possible to implement roughtime 
on small embedded systems.  The Merkle tree adds a bit of complexity, 
but I can see how useful it can be in letting a server handle many 
requests, so I do believe that the complexity is worth it.

First of all, is there some kind of problem statement? What is roughtime 
supposed to solve and what is its intended usage?

I have read the post from cloudflare at:

https://blog.cloudflare.com/roughtime/

What I take away from that post is that roughtime is intended to provide 
good enough time to be able to do certificate validation.

"Roughtime lacks the precision of NTP, but aims to be accurate enough 
for cryptographic applications, and since the responses are 
authenticated, man-in-the-middle attacks aren’t possible."

"But for many applications, precise network time isn’t essential; it 
suffices to be accurate, say, within 10 seconds of real time. This 
observation is the primary motivation of Google’s Roughtime protocol"

But if that's the use case I feel that roughtime is a bit overdesigned. 
If "within 10 seconds of real time" is good enough there is no reason 
for the protocol to keep track of time with a higher resolution than 
whole seconds. Having microsecond resolution for the timestamps is total 
overkill. Even the leap second handling is unnecessary if 10 second 
accuracy is good enough. The information about the UTC-TAI offset is not 
needed for certificate validation either.  So if the goal is to handle 
certificate validation the protocol could be simplified quite a lot.

I could see keeping some of the complexity and using roughtime as a more 
generic protocol for letting small embedded systems get decent time, and 
to be able to do it with less code complexity and less CPU usage than 
NTS. NTS requires TLS over TCP which is much too complex for many small 
embedded systems such as an AVR based Arduino. There are fairly small 
Ed25519 libraries available for AVR so it should be possible to 
implement a roughtime client on an AVR though. In that case I can see 
the usefulness of having better than second resolution for the 
timestamps and also keeping information about leap seconds.  And I guess 
there could be embedded applications that might be interested in the 
UTC-TAI offset even if I probably wouldn't use it myself.

But in that case I find the protocol slightly lacking. Even on a modern 
PC the processing time for just doing a Ed25519 signature for 32 bytes 
of data can be tens or even hundreds of microseconds.  Even hardware 
implementations in a FPGA have processing times of that order.

https://www.researchgate.net/publication/318230235_Low-Latency_X25519_Hardware_ImplementationBreaking_the_100_Microseconds_Barrier

The possible processing time is magnitudes larger than the resolution of 
the timestamps.  Since there is no receive timestamp defined in the 
roughtime message, only the transmit time, there is no way for a client 
to compensate for this processing time.  Basically, if the resolution is 
microseconds, the server response ought to include a receive timestamp 
similarly to NTP so that the processing time can be accounted for and so 
that the microsecond resolution actually matters.

An alternative would be to say that roughtime isn't supposed to be that 
accurate and use a lower resolution such as milliseconds for all 
timestamps.  That would also have the advantage that "milliseconds per 
day" would fit in a 32 bit unsigned integer with bits to spare.  That is 
not true for "microseconds per day" which requires 37 bits.  This might 
not sound like a big problem but doing a 37 bit division on an embedded 
system will probably require using a library which can perform 64 bit 
divisions.  And the increased code size for that can make a big 
difference on a small memory constrained AVR system.  Even 32 bit 
divisions can be painful on an AVR processor, so changing the definition 
of timestamps to whole seconds plus with a fraction which is a power of 
two might be better so that getting to the second part can be done with 
just a shift instruction.  This is something that I think NTP gets right 
by having a 64 bit timestamp where the high 32 bits are whole seconds 
and the low 32 bits are the fractional part.  A client which doesn't 
need the full 32 bit resolution for the timestamps can just mask off the 
lower bits.

I think it might also be good to remove some of the options in the 
protocol or make them mandatory.  If the UTC-TAI offset is needed by 
some clients and it is considered important enough to keep it should be 
a mandatory part of the protocol.  If it's optional I think there is a 
fairly big risk that it won't be implemented by many servers and a 
client might not get the UTC-TAI information from any of the servers 
that it queries.

As for the leap seconds, is it really necessary to provide a list of 
leap seconds in the response?  Wouldn't it be enough to just provide the 
one leap second.  Provide information on a future leap second a few 
days/weeks in advance, and keep providing the information about the leap 
second in the same field for a few days/weeks after it has occurred.  If 
I understand correctly there will never be two leap second events in 
such rapid succession that this will be a limitation.

So to summarize, in general I like roughtime.  The protocol could be 
slightly simplified, in my opinion some optional parts should either be 
removed or made mandatory just to keep the number of possible 
combinations down.

It would also be nice with some clarification on what the intended use 
of roughtime is.  If it's only for certificate validation a 10 second 
resolution is enough and the protocol could be made a lot simpler. But 
then it wouldn't be that useful for an embedded system which wants 
decently accurate time, such as for a ESP32 based wall clock.  If I as a 
human can see the difference between the wall clock and the time on my 
computer that would be a bit of a shame.

Personally I'd prefer if the goal would be to provide millisecond 
resolution and that it should be easy to implement on a memory/CPU 
constrained system.  With millisecond resolution, letting an embedded 
system sleep and then wake up to listen for a short radio beacon from 
some other system would be very doable.  But in that case I'd like to 
simplify the protocol slightly to make it easier to implement on small 
embedded systems.  Or decide that roughtime should go for a bit of 
overkill and future proofing by having microsecond resolution.  But in 
that case I'd like to add a receive timestamp to the response so that 
it's possible to make full use of the increased resolution.

So, nothing major really, but I think some small things could be 
improved, especially for someone wanting to implement roughtime on a 
small embedded system.

Regards,
     Christer