Subject: [TLS] 0-RTT in DTLS 1.3

From: Hanno Becker <[email-masked]>
Date: Sun, 23 May 2021 06:05:24 +0000

Hi,

Two short comments/questions on 0-RTT in DTLS 1.3, apologies if I missed something in the specs:

1) In DTLS 1.3, it would seem common for the server to send an HRR for the sake of return routability checking. TLS 1.3 forbids the use of 0-RTT after an HRR. So, 0-RTT can't be used in DTLS 1.3 if the server requires return routability checking -- is this understanding correct? Should this be stated more explicitly?

2) Not allowing 0-RTT after an HRR, or rather not allowing 0-RTT twice, seems important for DTLS 1.3 as we'd otherwise overload epoch 1. Is this worth stating?

Cheers,
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 24 May 2021 09:57:22 +1000

On Sun, May 23, 2021, at 16:05, Hanno Becker wrote:
> 1) In DTLS 1.3, it would seem common for the server to send an HRR for 
> the sake of return routability checking. TLS 1.3 forbids the use of 
> 0-RTT after an HRR. So, 0-RTT can't be used in DTLS 1.3 if the server 
> requires return routability checking -- is this understanding correct? 
> Should this be stated more explicitly?

This is not the model that QUIC uses.  Binding return routability information into session tickets allows 0-RTT to be used, albeit at some risk.  Managing that risk might take a few forms, the most common being limiting the total amount of response data and limiting the period over which 0-RTT is accepted (more than the 7 days).
 
> 2) Not allowing 0-RTT after an HRR, or rather not allowing 0-RTT 
> *twice*, seems important for DTLS 1.3 as we'd otherwise overload epoch 
> 1. Is this worth stating?

TLS already says that HRR automatically causes 0-RTT to be rejected.  "Early data is not permitted after a HelloRetryRequest." (RFC 8446, Section 4.1.2)

---

From: Hanno Becker <[email-masked]>
Date: Mon, 24 May 2021 04:19:07 +0000

Hi Martin,

> TLS already says that HRR automatically causes 0-RTT to be rejected.  "Early data is not permitted after a HelloRetryRequest." (RFC 8446, Section 4.1.2)

Yep, that's clear - my question was whether the DTLS 1.3 Spec should contain an explicit
reminder of that, e.g. when it claims that cryptographic material is uniquely identified
by epochs. This wouldn't be true if you could send 0-RTT after an HRR, in which case
you'd end up with an overloading of epoch 1.

Cheers,
Hanno
________________________________
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Monday, May 24, 2021 12:57 AM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] 0-RTT in DTLS 1.3

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 24 May 2021 14:32:04 +1000

> you'd end up with an overloading of epoch 1.

It's not necessarily the case that you would end up with an insecure protocol in this case.  It depends on how the keys for epoch 1 are derived.  As TLS equates HRR with early data rejection, there is no answer to the question of what keys would be used after HRR.

If you mean to refer to "Note this epoch is skipped if the client does not offer early data" it seems like you could adjust this to say "Note this epoch is skipped if the client does not offer **or the server rejects** early data".

---

From: Hanno Becker <[email-masked]>
Date: Mon, 24 May 2021 05:01:49 +0000

Hi,

> It's not necessarily the case that you would end up with an insecure protocol in this case.

One should rather ask: Is it necessarily the case that you would still end up with a secure protocol, and if so, why.

I don't see an attack either, but I think the binding of epochs to keys is fundamental
to DTLS, and if there's danger of violating it, this may well be worth pointing out.

For example, is it obvious enough that there cannot be any risk to early data confidentiality if a non-conforming
client sends two batches of 0-RTT after its first and second ClientHello, both with epoch 1 but with different keys?
Unless this can be ruled out easily, I think it would be worth adding an explicit reminder and/or entry in the
"Implementation pitfalls" section.

Cheers,
Hanno