[TLS] New TLS version negotiation mechanism, take 2

[Dave Garrett <[e-mail]>]

Based on feedback in the previous discussion, I think I've cobbled together a framework that might be good to use.

* A new extension that contains a single ProtocolVersion, with its value named max_version
* Rename ClientHello.client_version to min_version
* Rename ServerHello.server_version to negotiated_version
* Convert ProtocolVersion to a 16-bit enum, with equivalent values to existing struct format
* The values are as follows:

1) record layer version frozen to TLS_version_1_0(0x0301)  (PR #107)
2) ClientHello.min_version set to TLS_version_1_2(0x0303)
    (for clients supporting TLS 1.2, this is a constant;
     clients not supporting TLS 1.x set this to their higher min version)
3) Both endpoints set their max_version (in ext) to their max supported version
    (all clients send; all servers reply if clients send; these values are constant based on config)
4) ServerHello.negotiated_version is picked in a manner similar to now, but from the endpoints'
    max_version fields. If the new extension is not supported, it transparently falls back to
    TLS 1.2, and old servers will fall back to TLS 1.0/1.1 if needed.

Servers now have a min_version from client to not offer to fall back too far at all. Version IDs 0x0304 through 0x03FF can be assigned as IDs for upcoming draft versions. The final version will be assigned 0x0400. As there's no longer an attempt to do something vaguely akin to major.minor, the values are arbitrary and can be assigned for draft/experimental versions as needed. Negotiation logic specifies that servers picking a lower version must pick a stable version if the client did not explicitly offer a supported experimental version.

This seems to get pretty much what we want here:
+ TLS 1.3+ version intolerance is not an issue, unless the client refuses to negotiate TLS 1.x, in which case it doesn't matter. (it won't work regardless of the server responding ideally or not)
+ Only one extension with one fixed length value
+ Both stable and draft/experimental versions can use the same negotiation mechanism (and get tested)
+ It's more or less as simple as can be, given that we're hacking in a new mechanism on top of the old. Yeah, lots of version fields, but almost all are constants.
+ All the various version fields are now named so as to indicate what they're actually for

Ditching the version field from the encrypted records is a very good idea to go along with this, as it's useless and yet another version field to confuse things.

I've created a branch with a very WIP set of changes. I have not updated the backwards compatibility section for this new system fully yet. (just a bunch of TODOs listed there) The other appendix bits are not added either, and there's a few other spots that need some extra explanation. This is just to get the main idea of this proposal for discussion. This is based on PR #107:

https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett:NVN


Dave