TLS 1.2 servers ignore the supported versions extension

[goatgoose]

Problem:

s2n-tls currently keeps track of four separate TLS protocol version fields on a connection:

• server_protocol_version: The highest protocol version supported by the server.
• client_protocol_version: The highest protocol version supported by the client.
• client_hello_version: The protocol version advertised in the client hello itself. This field isn't used in TLS 1.3 to determine the client's protocol version, so is always set to TLS 1.2 if the client supports TLS 1.3.
• actual_protocol_version: The protocol version selected for the connection. This is the highest protocol version supported by both the server and client.

Currently, s2n-tls servers set the client and actual protocol version fields differently depending on the server protocol version. The server_protocol_version field can either be TLS 1.2 or TLS 1.3, depending on if TLS 1.3 is supported by the libcrypto and supported by the server's security policy.

If the server protocol version is TLS 1.3 and a supported versions extension is received from the client, the server will use this extension to determine the client_protocol_version field and the resulting actual_protocol_version field. If the supported versions extension is received, the server will never attempt to use the client_hello_version field to determine the client and actual protocol versions, even if a compatible version can't be determined from parsing the extension. This behavior is compliant with the RFC:

If this extension is present in the ClientHello, servers MUST NOT use
the ClientHello.legacy_version value for version negotiation and MUST
use only the "supported_versions" extension to determine client
preferences.

However, if the server protocol version is TLS 1.2 and a supported versions extension is received, the extension is ignored. Instead, the client hello version is used to determine the client_protocol_version field and the resulting actual_protocol_version field. This behavior is not compliant with the RFC, since the supported versions extension should always be used to determine the client's supported versions if it was received.

This protocol version selection behavior of TLS 1.2 servers was implemented for backwards compatibility. The intention was to not alter the behavior of TLS 1.2 servers due to a TLS 1.3 extension. However, changing TLS 1.2 servers to respect the supported versions extension seems relatively low risk. The RFC specifically states that the extension should include ALL supported versions, not just TLS 1.3:

Implementations of this specification MUST send this extension in the
ClientHello containing all versions of TLS which they are prepared to
negotiate (for this specification, that means minimally 0x0304, but
if previous versions of TLS are allowed to be negotiated, they MUST
be present as well).

And it's stated that protocol versions less than TLS 1.3 may be selected from the extension:

Servers MUST only select a version of TLS present in
that extension and MUST ignore any unknown versions that are present
in that extension. Note that this mechanism makes it possible to
negotiate a version prior to TLS 1.2 if one side supports a sparse
range.

By implementing this change, s2n-tls would become more compliant with the RFC. Additionally, TLS 1.2 servers would negotiate protocol versions more closely aligned with the client's intent. For instance, a client could send a client hello with version TLS 1.0 and a supported versions extension containing TLS 1.0 and TLS 1.2. Currently, a TLS 1.2 server would negotiate TLS 1.0, but with this change it would negotiate TLS 1.2 instead.

However, there are some risks associated with this change:

• Since this is a TLS 1.3 extension, it seems possible that some misbehaved clients could send this extension assuming that it will be ignored if the server doesn't support TLS 1.3. In this case, the client could decide to put only TLS 1.3 in the extension even though it also supports TLS 1.2. This would mean that TLS 1.2 servers would start to fail to negotiate with these clients. This could be mitigated by falling back to the client hello version if a compatible version couldn't be determined by the extension, but this behavior would not be compliant with the RFC.
• It's possible that some clients send malformed supported versions extensions. In this case, TLS 1.2 servers would start to fail to negotiate with these clients. This could again be mitigated by falling back to the client hello version, but this behavior would not be compliant with the RFC.

Solution:

We should consider changing TLS 1.2 servers to use the supported groups extension to determine the client's supported versions, rather than using the client hello version.

• Does this change what S2N sends over the wire?
  • Yes: this change could impact what protocol version is selected.
• Does this change any public APIs?
  • No.
• Which versions of TLS will this impact?
  • All versions less than TLS 1.3, but only applicable to servers that support a maximum version of TLS 1.2.