Subject: [Ntp] 0-RTT for NTS-KE

From: Daniel Franke <[email-masked]>
Date: Wed, 29 Aug 2018 10:56:12 -0400

Now that RFC 8446 is final I think there should be some discussion in
the NTS document about sending NTS-KE requests as 0-RTT data,
concluding with "don't do it". At first blush it seems like a tempting
idea, because it's harmless for servers to process replayed NTS-KE
requests, and because it seems like it should eliminate the round-trip
where servers need to hold TLS session state. Unfortunately, the
latter property requires a lot of kludges to actually achieve, because
servers aren't normally expected to hang up the moment they've
responded to 0-RTT data; at that point the handshake is still in
progress and the server is still awaiting the client's Finished
message. With enough hacking into the internals of your TLS library
you could probably find a way to handle the aborted handshake
gracefully, but I think this is too much to ask of NTS-KE
implementers. NTS-KE was designed from the beginning to make the one
round-trip worth of state tolerable for even the busiest servers, and
I don't think it's worth adding complexity to reduce this burden any
further.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 Aug 2018 17:13:37 +0200

On Wed, Aug 29, 2018 at 10:56:12AM -0400, Daniel Franke wrote:
> concluding with "don't do it".

Unless there is an impact on security, or some other good reason, I'd
prefer "do it if you can".

This was the main feature of the stateless server NTS design when we
were still considering to use DTLS and I think it will be useful even
with TLS.

> With enough hacking into the internals of your TLS library
> implementers.

If there is a good use case, I'm pretty sure the TLS libraries will
accept patches to support it if they don't do it already.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Aug 2018 15:22:59 +0000

I think MAY NOT support 0RTT is probably enough.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Aug 2018 15:26:13 +0000

Agree, but "do it if you want" :)

---

From: Daniel Franke <[email-masked]>
Date: Wed, 29 Aug 2018 11:38:34 -0400

> prefer "do it if you can".

But there *is* on security in form of increased implementation and
specification complexity. It adds a new permissible transition to the
TLS 1.3 state machine, transforming it into something that's not quite
TLS 1.3 and we presume is still secure but hasn't really be analyzed.
It requires adding a new flag "0-RTT safe" flag to the IANA registry
for every record type and requiring that the enforcement logic be
correctly implemented. Even if you get all this right, it'll seldom be
usable anyhow because if you need to do a new NTS-KE handshake then
you usually either don't have a TLS PSK yet, or you did but one side
has lost track of it. Tell me again what benefit we're getting here?

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 Aug 2018 18:21:49 +0200

> has lost track of it. Tell me again what benefit we're getting here?

I don't know how is the TLS PSK involved here.

As I understand it, with 0-RTT it would be possible to increase the
number of concurrent NTS-KE sessions using the same amount of memory.
On small devices with very limited memory that could be useful.

If TLS 1.3+0-RTT was a requirement, it might also make DoS attacks
more difficult, but I understand that may not be practical yet.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Wed, 29 Aug 2018 12:34:44 -0400

0-RTT is only possible if you already have a key pre-shared with the
server. The mechanism for managing these PSKs works just like the NTS
cookie mechanism, with TLS session tickets taking the place of cookies. To
preserve forward secrecy, TLS servers periodically rotate out the keys they
use to generate and later decrypt session tickets, just like NTS servers
are encouraged to rotate out the keys they use for generating and later
decrypting cookies. If you're doing NTS-KE, then you either don't have a
PSK with the server and can't even attempt 0-RTT, or all your NTS cookies
have expired, in which case you can try 0-RTT but it'll probably fail
because your session tickets have probably expired too.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 29 Aug 2018 19:40:12 +0200

> because your session tickets have probably expired too.

Thanks. This all makes sense.

However, I seem to remember it differently with what we were
originally trying to do with DTLS. Maybe that's because the client
wasn't sending any application data, so there was no need for a PSK?

Just curious, are there any client messages in the current NTS-KE that
need to be encrypted?

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Wed, 29 Aug 2018 20:09:52 +0200

If I understand it right you can only do 0-RTT if you want to resume a session. I don't see that this as a relevant scenario within NTS because the initial NTS-KE has to be done only once and than - hopefully for a long time - the NTP association is protected by the NTS extension fields. Therefore I tend to agree with Daniel to recommend to "don't do it".

Dieter

-----"ntp" <[email-masked]> wrote: -----

>To: "Daniel Franke" <[email-masked]>
>From: "Miroslav Lichvar" 
>Sent by: "ntp" 
>Date: 08/29/2018 19:40
>Cc: [email-masked]
>Subject: Re: [Ntp] 0-RTT for NTS-KE
>
>_______________________________________________
>ntp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ntp
>