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
On Mon, May 24, 2021, at 14:19, Hanno Becker wrote:
> 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
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
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
Issues
--
* tlswg/draft-ietf-tls-esni (+0/-0/💬5)
2 issues received 5 new comments:
- #433 Embedded ClientHello padding complicates whole-input padding schemes (1
by davidben)
https://github.com/tlswg/draft-ietf-tls-esni/issues/433
- #429 Clarify handling of transcript at client? (4
