Hi Ilari, On 07/04/2016 11:18 PM, Ilari Liusvaara wrote: >> > IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send >> > HRR. > Yes, DTLS 1.3 servers can't send HVR, but that doesn't mean DTLS 1.3 > clients can't receive HVR (and then need to handle it somehow). > > And if downnegotiation is to be possible, then that way should be > compatible with DTLS 1.2 (sticking the cookie into legacy cookie > field and clearing the hash should be compatbile enough). >
Consider the following three cases: * Client supports DTLS 1.2 / 1.3 but the server supports only DTLS 1.2. If the client starts the exchange with DTLS 1.3 then the server could return a HelloVerifyRequest as defined in DTLS 1.2 and the exchange can continue. For the client it is not a problem to deal with the HVR since it supports both stacks. * Client supports only DTLS 1.3 and server supports DTLS 1.2/1.3. Here the client starts with a DTLS 1.3 exchange and the server will only reply with a HelloRetryRequest as defined in TLS 1.3. It should bother dealing with the DTLS 1.2 functionality when interacting with a DTLS 1.3 client. * Client supports only DTLS 1.2 and the server supports DTLS 1.2/1.3. In this case, the client starts with the regular ClientHello and the server will determine based on the version that it has to proceed with DTLS 1.2. I believe that this could work fine. Ciao Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
