On Tue, Jul 05, 2016 at 10:42:08AM +0200, Hannes Tschofenig wrote: > > 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.
There are two more cases if server-side fallback is possible. One that can't work at all (fallback below minimum supported version) and another where the server has to be careful what cookie field it uses. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
