On 11/03/2014 04:16 PM, Leif Johansson wrote: > We are currently looking at a pretty thin agenda for Honolulu. > > Agenda requests are not like wine: they don't improve with age.
The TLS WG has been struggling with the "fallback dance" done by major browsers (and possibly some other TLS clients. The fallback dance represents an attempt to establish a TLS connection to a peer that fails to implement the version-negotiated handshake properly the first time. As such, it's not part of the TLS protocol itself, but more than one vendor appears to think it's necessary to improve connectivity. I wonder if that puts the fallback dance in the purview of UTA. I am unaware of any documents that explicitly describe the best practice for doing such a thing, or if there are different kinds of fallback approaches that different clients might pursue. The recent https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 describes a mechanism for use by implementations that perform some sort of fallback, without having any document to reference for fallback best practices. Some questions that come up around fallback: * should fallback address only choice of TLS versions (min and max), or should it address other features like extensions and ciphersuites? some ciphersuites are not available in some versions, and very old versions are extension intolerant * should fallback happen one level at a time, or are there arguments for falling back all the way to weakest/most-compatible handshakes? * how should stateful TLS clients store state about what versions of fallback were required to reach any given TLS server? --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
