Subject: [Ntp] No more options for NTP

From: Watson Ladd <[email-masked]>
Date: Sat, 6 Apr 2019 09:07:11 -0700

Dear all,

This might be a terrible idea, but now that we have NTS-KE with protocol
negotiation I propose we use that for all capability negotiation to
encourage adoption of NTS and to avoid the issues with NTP extensions. Also
kill the MAC.

If we want a v5 I think that should be negotiated via NTS for flexibility.

Sincerely,
Watson

---

From: [email-masked]
Date: Tue, 16 Apr 2019 09:10:53 +0200

Hey all, hey Watson,

I can't speak for everyone of course, but personally, I felt that I 
couldn't comment on the suggestion because I didn't feel I understood 
enough of what it entailed.
Would you care to elaborate a bit on how you propose this would  work?

On the issues I think I understood enough to comment:
- End the use of all non-EF MACs: I agree that use of EF-MACs is 
preferable, but I don't know that just forbidding use of the non-EF MAC 
fixes everything (and I'm unsure what document to even place such a 
regulation in)
- Using NTS (-KE) for any and all capability negotiation: I agree insofar 
that it is preferable over using potentially unsecured fields for this 
(because unsecured negotiation seems like a bad idea generally), but am 
not convinced that this is a good issue for normative language. For one, 
it would seem to kill the option to use anything other than NTS forever 
(at least without first using NTS to communicate that one wishes to use an 
alternative to NTS)

One concrete question: In your comment about a v5, what exactly is the 
"that" that you propose to negotiate via NTS?

Overall though, I wish there was more discussion on this proposal (I have 
seen zero, have I missed anything?). 
If people disagree, stated disagreement seems more useful that silence.
But as I hinted at, perhaps the lack of discussion is related to the 
open-endedness of the suggestion?

Best regards,
Kristof

Von:    "Watson Ladd" <[email-masked]>
An:     "NTP WG" <[email-masked]>
Datum:  06.04.2019 18:08
Betreff:        [Ntp] No more options for NTP
Gesendet von:   "ntp" <[email-masked]>

Dear all,

This might be a terrible idea, but now that we have NTS-KE with protocol 
negotiation I propose we use that for all capability negotiation to 
encourage adoption of NTS and to avoid the issues with NTP extensions.. 
Also kill the MAC. 

Sincerely,
Watson_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 16 Apr 2019 10:21:28 +0200

> open-endedness of the suggestion?

It's not very clear to me what would be the advantage of not using NTS
after the KE. If the client is complex enough to support TLS, why not
just authenticate the packets? Is an NTS server (e.g. returned in the
server negotiation record) actually required to respond to requests
not authenticated by NTS?

I suspect we would need to distinguish between NTP and NTP+NTS as next
protocols. The plain NTP protocol could be specified in a separate
draft, but in the NTS-for-NTP draft the next protocol #0 would need to
be renamed to something more specific.

-- 
Miroslav Lichvar

---

From: Watson Ladd <[email-masked]>
Date: Wed, 24 Apr 2019 07:57:47 -0700

> Would you care to elaborate a bit on how you propose this would  work?
Certainly.

The goal I have is to sunset NTP without security as well as provide
solution to the problems of NTP v4

When I look at proposals like I-Do or the smearing proposal, or interleaved
mode, these have to be very painfully arranged because extensions in NTP
are broken. But NTS provides a similar client advertises capability and
server selects capability flow, and is not constrained by the need to
maintain close similarity to NTP or eschew extensions. Something like an
I-Do inquiry sent in the client NTS-KE request and then responded to in the
server's response in a new packet type would provide a feature discovery
mechanism. I think this will be a much more flexible approach then
proposals that try to cram everything into a packet.