Subject: [Ntp] Why NTPv5 should be based on TLS

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 16:06:57 +0000

NTS has a clean, and large, separation between TLS and NTP. The WG should consider if this is still the right thing to do.

One of the things we could gain by doing this is being able to use zero round-trip/early data (0RTT). For example, when a client returns to a server that it has aleady authenticated, it can send a request as part of its hello message, and the server can reply as part of its handshake; no extra round-trips required.  (There is a weakness around being able to reply messages, but I think most NTP messages are idempotent, like HTTP GET, so this is not a concern here.)

Another thing might be the ability to use UDP and DTLS.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 5 Jan 2021 11:18:25 -0500

I discussed the possibility of a design like this, and the problems with
it, way back in 2016:
https://mailarchive.ietf.org/arch/msg/ntp/rhjalqdif83Ojjb2VNzZASHzSCg/. I
don't think anything has changed that would invalidate any of the arguments
against it.

On Tue, Jan 5, 2021 at 11:07 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> NTS has a clean, and large, separation between TLS and NTP. The WG should
> consider if this is still the right thing to do.
>
>
>
> One of the things we could gain by doing this is being able to use zero
> round-trip/early data (0RTT). For example, when a client returns to a
> server that it has aleady authenticated, it can send a request as part of
> its hello message, and the server can reply as part of its handshake; no
> extra round-trips required.  (There is a weakness around being able to
> reply messages, but I think most NTP messages are idempotent, like HTTP
> GET, so this is not a concern here.)
>
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Kyle Rose <[email-masked]>
Date: Tue, 5 Jan 2021 11:22:53 -0500

There's a reason NTS was designed the way it was: to benefit from the work
put into securing the TLS handshake while minimizing error in RTT
measurement for packets involved in time synchronization. That means a
bespoke time synchronization protocol as close as possible to the wire,
with easily-bounded on-machine jitter, rather than the black box of TLS or
DTLS. I continue to believe this is the right approach.

Kyle

---

From: James <[email-masked]>
Date: Wed, 6 Jan 2021 10:08:07 +0000

In lieu of a more suitable alternative, I woulld tend to agree with this
direction.

However, I think there is benefit in looking at re-visiting an approach
that uses TESLA (RFC 4082). It appears this was brought up on list back
in 2016[1] but did not really move forward for reasons I'm unable to
ascertain.

- J

1: https://mailarchive.ietf.org/arch/msg/ntp/fx8tWJUu06ZKPYRdyRY8px72TcE/

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jan 2021 17:32:29 +0000

direction.

Daniel posted a link to a previous analysis he did, which I found useful but not compelling.  Kyle pointed out that it's important to measure the cost of the crypto work to keep the timestamp calculations accurate, which is more compelling to me. I'm not yet convinced, (0RTT request/response seems compelling to me), but I'm willing to admit I'm in the minority if that's what the WG decides.

I am more interested in having the WG as a whole discuss the issue than I am about what the decision is. :)

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 6 Jan 2021 13:42:31 -0700

> On Jan 6, 2021, at 10:32 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

Maybe I’m missing something, but as long as the cost of the crypto operations are constant, and don’t increase jitter, that’s indistinguishable from propagation delay, isn’t it?

---

From: Hal Murray <[email-masked]>
Date: Wed, 06 Jan 2021 13:27:40 -0800

[email-masked] said:
> Maybe I’m missing something, but as long as the cost of the crypto operations
> are constant, and don’t increase jitter, that’s indistinguishable from
> propagation delay, isn’t it? 

Right.  But if the client and server are running on different speed CPUs the 
crypto operations will take different times and that will introduce an error 
just like asymmetric routing does.

And if one side fixes the error (somehow) and the other side doesn't that will 
introduce an obvious error even when they have the same speed CPUs.

-- 
These are my opinions.  I hate spam.

---

From: Kyle Rose <[email-masked]>
Date: Wed, 6 Jan 2021 16:32:38 -0500

On Wed, Jan 6, 2021 at 3:42 PM Philip Prindeville <
[email-masked]> wrote:

>
> Maybe I’m missing something, but as long as the cost of the crypto
> operations are constant, and don’t increase jitter, that’s
> indistinguishable from propagation delay, isn’t it?
>

It's very hard to do that with a black box like DTLS. What if someone
negotiates a non-constant-time AEAD (as dumb as such a thing might be)?
What if there's an extension or update published for DTLS that impacts the
timing? More generally, as you add layers, you increase the volume of code
and number of layer interactions that can introduce error.

For a protocol whose very purpose requires a high degree of precision, a
bespoke protocol with characteristics that are shrink-wrapped around chosen
properties is going to be the safest approach. General crypto is great at
lots of things, including NTS key exchange. It's not the best solution for
NTP.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jan 2021 21:35:27 +0000

>    Maybe I’m missing something, but as long as the cost of the crypto operations are constant, and don’t increase jitter, that’s indistinguishable from propagation delay, isn’t it?

Sure, but this was in the context of using TLS 0RTT during the handshake, which is less predictable.

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 6 Jan 2021 22:59:05 +0100

On Wed, Jan 06, 2021 at 01:27:40PM -0800, Hal Murray wrote:
> > Maybe I???m missing something, but as long as the cost of the crypto operations
> > are constant, and don???t increase jitter, that???s indistinguishable from
> > propagation delay, isn???t it? 
> 

If you compensate for it, even if it's just one side, you will
reduce the maximum error by almost that amount. It might increase
the real error.

Kurt

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 09:33:15 +0100

>>> Kyle Rose <[email-masked]> schrieb am 06.01.2021 um 22:32 in Nachricht
>> indistinguishable from propagation delay, isn’t it?

perfect crypto has constant runtime, but most crypto isn't perfect it seems.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 13:22:34 +0000

>    perfect crypto has constant runtime, but most crypto isn't perfect it seems.

Constant-time is pretty much table stakes these days, available everywhere.

---

From: "Dieter Sibold" <[email-masked]>
Date: Thu, 07 Jan 2021 21:06:01 +0100

The usage of Tesla within NTS was proposed in order to protect NTP’s 
broadcast/multicast mode. At some point the WG decided to not consider 
these modes from NTS and to focus on the client/server mode only. 
Therefore, there was no need to pursue Tesla for NTS anymore.

IEEE 1588:2019 considers a TESLA like approach in order to achieve 
strong source authentication of the PTP grandmaster. It is somehow 
cumbersome because Tesla in itself depends on rough time sync between 
slaves and master.

Dieter

On 6 Jan 2021, at 11:08, James wrote:

> 1: 
> https://mailarchive.ietf.org/arch/msg/ntp/fx8tWJUu06ZKPYRdyRY8px72TcE/
>
>> NTS has a clean, and large, separation between TLS and NTP. The WG 
>> should consider if this is still the right thing to do.
>>
>> One of the things we could gain by doing this is being able to use 
>> zero round-trip/early data (0RTT). For example, when a client returns 
>> to a server that it has aleady authenticated, it can send a request 
>> as part of its hello message, and the server can reply as part of its 
>> handshake; no extra round-trips required.  (There is a weakness 
>> around being able to reply messages, but I think most NTP messages 
>> are idempotent, like HTTP GET, so this is not a concern here.)
>>