[TLS] A new TLS version negotiation mechanism

[Dave Garrett <[e-mail]>]

A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+. It'll be needed to handle draft implementations, if desired, and I think it might just be wanted for all negotiation. TLS 1.3 version intolerance is currently surveyed to be in the ~1.5% range [1]. The simplest method is to do so via a new mandatory extension, as has been suggested by people before. Here's a straightforward outline to get the ball rolling.

Versions would be negotiated with a new "Extended TLS Version Negotiation" extension with the following contents:

struct {
  uint8 versions<0..2^8-1>;
} SupportedVersions;

where versions contains an ordered list of the supported TLS minor versions. A block of numbers would be reserved for draft versions. (e.g. ID 32+ for drafts)

ClientHello would include the extension with its supported versions list. IFF a server receives the extension, then it would include its corresponding set in its ServerHello. (if no version is negotiated, this would make error reporting/diagnosis much better) The ServerHello.version would still be set to the version picked by the server, now the highest supported version from the client's set that the server supports. The ClientHello.version in this negotiation mechanism would be frozen to {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2. Clients could set this to {0,0} to force only the new mechanism with no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are all undesirable). The set of valid values for this field would be limited to exactly 5.

Additionally, I propose dropping the TLSCiphertext.version field entirely. (needs PR #51 [2] or similar; PR #51 primarily proposes encrypting ContentType, also a good idea) It's a waste of 2 bytes per record. TLSPlaintext.version would have to stay for backwards compatibility (see PR #51). Version handling would be restricted to just the hellos.

Why?
1) Too many implementations botched the existing version negotiation mechanism.
    This one requires nothing new for existing implementations to handle. (transparent fallback to TLS 1.2)
2) This method allows for non-continuous version support to be negotiated.
    (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4)
3) Draft implementations would be easily negotiable using the same method as release.
    (HTTP/2 benefited from widespread testing of drafts; doing so here could be helpful too)
4) Client implementations are not encouraged to go back to the old habit of insecure fallback, nor rely on SCSV for TLS 1.3+.
5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Microsoft could tolerate. They don't like SCSV as-is [3], and I tend to agree with their sentiment.
6) In the event of handshake failure due to an unsuitable version selected by the server, the client will have received a SupportedVersions set from the server to know exactly what is and is not supported.

Why not?
1) Kinda ugly to freeze a hello field and hack in a new negotiation method.
2) Some people don't like advertising all supported versions openly.
    (TLS 1.0-1.2 could be left out of the list to force only old implementations to consider them)
3) Failing to connect to the broken ~1.5% of servers that can't negotiate correctly is the "Right Thing To Do".
4) A few extra bytes in the hello messages. (though, far fewer overall if record layer is changed as proposed)

I would prefer to get PR #107 [4] committed prior to a brand new mechanism, if possible.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg15141.html
[2] https://github.com/tlswg/tls13-spec/pull/51
[3] http://www.ietf.org/mail-archive/web/tls/current/msg15391.html
[4] https://github.com/tlswg/tls13-spec/pull/107


Comments?


Dave