Subject: Re: [Ntp] Should NTPv5 have QUIC bindings?

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 12:23:13 -0700

Salz, Rich said:
>    Curious to hear what people think.

What problem(s) do you think it will solve?

Time transfer seems to be splitting into 2 areas.

One is interested in accuracy.  Consider PTP.

The other is interested in simplicity.  Consider your local home modem/router.

-------

I could see the simple end splitting into 2 sub-areas.  One would focus on 
simplicity, say without certificates or TLS.

The other would focus on security so they probably have certificates and a 
mechanism to keep them up to date.  Using QUIC would avoid having to think 
about NTS.

Do the QUIC APIs support something like SO_TIMESTAMP?

-- 
These are my opinions.  I hate spam.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Oct 2021 19:38:42 +0000

> What problem(s) do you think it will solve?

Nothing definitive which is why I asked.  The IETF is moving to QUIC for many things, so I'm curious.

>    Time transfer seems to be splitting into 2 areas.

Interesting thesis.

>    Do the QUIC APIs support something like SO_TIMESTAMP?

There's a draft proposal to add it: https://tools.ietf.org/id/draft-huitema-quic-ts-05.html is one place to find it.

---

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 13:29:59 -0700

> Nothing definitive which is why I asked.  The IETF is moving to QUIC for many

I think you neet to talk to a QUIC wizard.

I'm assuming the idea is to replace NTS with QUIC.

One of the goals of NTS was to avoid per-connection storage on the server.  It 
uses TLS to get cookies that hold the connection info.  I don't see how to do 
that with QUIC.

As I understand it, if you are interested in performance, there are 2 types of 
crypto.  RSA is slow.  AES if fast.  AES requires shaared keys.  TLS uses RSA 
to setup a connection that holds the shared key.

I don't know enough about QUIC to count packets.  It looks to me like QUIC 
would either have to retain connections on the server or go through the 
connection setup for each NTP exchange.

It's worth considering retaining connections.  Again, I don't know any QUIC 
details, but memory is cheap these days.  It's worth considering keeping a 
connection for each client.  That might not work for something like the NIST 
servers but it could work for almost everything else.

----------

I saw mention of QUIC not using the IP Address for a connection key.  That 
sounds like an invitation for easy tracking.  If we take non-tracking as a 
serious goal, that could be enough to knock QUIC out of consideration.

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Oct 2021 22:48:36 +0100

> uses TLS to get cookies that hold the connection info.  I don't see how to do

I guess the client could use 0-RTT session resumption, which uses a
session ticket held by the client to retain state (such as the symmetric
crypto key) between queries. I don't know if QUIC allows the server to
close the session immediately with its first response packet, so it can
reply and immediately forget about the client, or if the server will have
to keep state for at least 1 RTT per query.

> serious goal, that could be enough to knock QUIC out of consideration.

Hmm, I can't find anything useful about the privacy considerations of
0-RTT in QUIC or in TLS/1.3. One advantage of using a popular security
layer ought to be that it deals with issues like this so NTP would not
have to worry at all...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
defend the right to speak, write, worship, associate, and vote freely