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 protected]> on behalf of Martin Thomson <[email protected]> Sent: Monday, May 24, 2021 12:57 AM To: [email protected] <[email protected]> Subject: Re: [TLS] 0-RTT in DTLS 1.3 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) _______________________________________________ TLS mailing list [email protected] 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.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
