The IMO most reasonable way forward would be to side-step the TLS version negotiation through ClientHello.client_version entirely, because of the well-known interop problems.
Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the offered list of TLS cipher suites as an indication that a TLS client is capable and willing to actually _use_ TLSv1.2, even when ClientHello.client_version might indicate (3,2) or (3,1) for better interop. The same approach will work for TLSv1.3, where the presence of a TLSv1.3 could be used to tell the server that the client is capable and willing to talk TLSv1.3, even when ClientHello.client_version might indicate a lower version of the protocol. Only the client is in the position to decide whether aborting the TLS handshake and retrying with a more feature-creeping ClientHello could provide additional benefits to the client (that it previously didn't offer, for whatever reason), and only the client is in the position to know how many TLS handshake attempts with which properties it previously attempted, and when to better stop retrying automatically and silently and to perform risk management (such as warning user/admin that something odd is going on). To get a smooth migration to using newer TLS protocol versions, we first need to define a scheme that lets new implementations recognize each other without upsetting the installed base. We know what works, the code points already exist, we will just have to align the documented semantics to provide a more forward-interoperable and more reasonable behaviour. Viktor Dukhovni wrote: > >> David Benjamin <david...@chromium.org> wrote: >> >> I'm not sure I follow. The specification certainly spells out how >> version negotiation is supposed to work. That hasn't stopped servers >> from getting it wrong. Fundamentally this is the sort of thing where >> bugs don't get noticed until we make a new TLS version, and we don't >> do that often enough to keep rust from gathering. > > A better way to keep rust from gathering is to not instutionalize fallback, > force the broken sites to deal with the issue. It's not the sites, but rather the software vendor providing the underlying TLS implementation. Sometimes you don't actually have a choice and an alternative to using what exists. > > While 2% is noticeable, you can probably drive 1.3 version intolerance > out of the ecosystem relatively quickly if Chrome implements fallback > for a limited time (say 6 months after TLS 1.3 RFC is done) and with > a diminishing probability (60% first month, 10% less each month > thereafter), season to taste. There exist various different flavour of TLS version intolerance, and the amount of defective servers out there is probably much larger. The entire installed base of Windows 2008R2 and Windows 20012R2 is TLS version intolerant with respect to TLSv1.2. If you send propose TLSv1.2 inside an SSLv2Hello to such a server, it will negotiate TLSv1.1 (rather than TLSv1.2). If you send an extensionless SSLv3 Hello proposing TLSv1.2, these Windows server with choke and close the network connection. An extension-less SSLv3 Hello with at client_version = TLSv1.1 or TLSv1.0 will succeed. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
