Hi Ekr, ~snip~
> I think the obvious way is: > > - Cookies from HelloVerifyRequest go to legacy cookie field. > - Cookies from HelloRetryRequest go to extension cookie field. > > If you don't do the first, you can't downnegotiate successfully. And > if you don't do the second, you would have to have special case with > cookie sizes (since HRR can transmit >255 byte cookie, which would be > too big for legacy cookie). > > > IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send > HRR. That makes sense to me. Btw, Section 11 "IANA Considerations" says that the Cookie extension is encrypted in the HelloRetryRequest message. I wonder whether this is a mistake particularly in the combination where the server returns the cookie as part of the incorrect key share (and therefore does not yet have a key to create the EncryptedExtension). The table should also say that the cookie is also contained in the ClientHello (in clear, unless it is a 0-RTT handshake). > > > > > - The handshake retransmit scheme doesn't seem to work that > > > well with post-handshake auth, and even less well with > > > session tickets. > > Why do you think so? Of course, unreliable transports creates > > inconvenience; is it that what you are referring to? > > DTLS assumes handshake messages are reliable, and that reliability is > implemented via handshake messages ACKing one another. > > - Session tickets have no ACK at all. > > > DTLS 1.3 should add an ACK, IMO. Sounds reasonable. > > > > - CertificateRequest can have very slow ACK. > - KeyUpdate has no real ACK (and isn't idempotent either). > > > Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch > instead. Ok. Ciao Hannes > > -Ekr > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
