Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

[James <[e-mail]>]

> On 18 Oct 2021, at 16:33, Miroslav Lichvar <[e-mail]> wrote:
> 
> I still don't understand this part. What do "as a default" and
> "authentication the minimum" exactly mean? What information needs to
> be encrypted? Everything? The first octet cannot be encrypted to allow
> detection of NTPv5 packets on the port 123.

Authentication does not imply confidentiality. Where confidentiality is employed I think it’s a reasonable assumption that the entire payload would not be confidential (but all could be authenticated) and that version detection and other information that is needed in clear can do so.

> For NTPv5 to be successful in replacing NTPv4, I think it needs to
> support no authentication, symmetric keys and NTS.

As I said to you last year, no authentication is fine but the protocol MUST prevent downgrade of it - to be explicit, an untrusted adversary removing it. I’m unsure given the simplistic nature of NTPv4 that this is feasible without just mandating it all the time, but I’m happy to consider other approaches that lead to the requirement being met.

> They can be supported both as different timescales, server responding
> in the one that the client has requested.
> 
> If you don't allow leap smearing in NTPv5 at all, I suspect people
> will either stick to NTPv4, missing the important improvements in
> NTPv5, or ignore the specification and use a leap-smeared version of
> NTPv5 anyway.

I’m not sure “we have to do it like x or people will ignore the specification” is an appropriate position to take. Our choices are:

* Smear in the server, and be at odds with attempting to be a linear, monotonic timescale and have an accuracy penalty to all clients and limit how they can source time. If this is what NTPv5 does it should signal both the presence of potential smearing as well as when smearing is happening, and we have to answer my previous comments regarding smearing cadence.
* Have the client handle smearing the clock it synchronises, which removes all the negatives of server smearing at the cost of doing this computation. This means a mixture of clients who want UTC or TAI can use the same server, and each client can do its own business regarding cadence.

> It seems we need to agree on some very high level goals for NTPv5. Is
> it supposed to replace most NTPv4 use cases? Is it supposed to be
> implementable on current operating systems?

I absolutely agree with this, and in part that’s what my document is trying to cover but we’ve all been too busy arguing about the other points. To answer your questions I would say “yes” to both (and I cover use cases in my document) but we should also be explicit about what use cases are not in scope. I’m happy to take suggestions for prose from you or anyone on list.

- J