Hello everybody, Here is a proposal for change aiming at removing the deprecated fields in ClientHello in a future TLS version.
This proposal would consist in changing the ClientHello structure from :
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
to :
struct {
ProtocolVersion legacy_version;
Random random;
select (ClientHello.legacy_version) {
case 0x0303: /* TLS v1.2 */
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
case 0x0304: /* TLS v1.3 */
CipherSuite cipher_suites<2..2^16-2>;
}
Extension extensions<8..2^16-1>;
} ClientHello;
With the following constraints :
- TLS 1.3 Servers MUST correctly parse ClientHello with
ClientHello.legacy_version either set to 0x0303 (TLS1.2) or 0x0304
(TLS1.3), and MUST NOT use this field's value for any other purpose than
parsing the ClientHello (notably, il MUST NOT be used to negociate the
protocol version, this is the role of the SupportedVersions Extension)
- TLS 1.3 Clients MUST set ClientHello.legacy_version either to 0x0303
(TLS1.2) or 0x0304 (TLS1.3)
- TLS 1.3 Clients SHOULD set ClientHello.legacy_version to 0x0303 (TLS1.2)
- TLS 1.3 Clients MAY set ClientHello.legacy_version to 0x0304 (TLS1.3)
present knowledge that the server supports TLS 1.3.
The idea is to use the legacy_version field to indicate the ClientHello
structure, rather than just being a deprecated field.
This way, a future release may only allow the 0x0304 value for
ClientHello.legacy_version without breaking compatibility with TLS 1.3
implementations.
This would be a reasonable change once TLS 1.2 is completely phased out,
or deemed too insecure to be used anymore.
It would then allow switching the ClientHello structure to :
struct {
ProtocolVersion legacy_version = 0x0304; /* TLS v1.3 */
Random random;
CipherSuite cipher_suites<2..2^16-2>;
Extension extensions<8..2^16-1>;
} ClientHello;
I kept the name legacy_version in this email for the sake of clarity,
but if it is decided to make such a change, it would probably be
pertinent to rename it.
client_hello_version, for example, might be a viable candidate.
A few other notes about the implications of such a change :
- The client side of the implementation is completely unchanged by this
modification
- The modifications to do to server implementations are minor, and not
likely to present any difficulty
- The current deprecated fields are not likely to be ever used again in
the future. If we need to add anything to the ClientHello, we would
likely use Extensions regardless of the presence or not of these
deprecated fields.
I could not think of any security or interoperability issue with this
proposal, the only drawback I can see being the slight complexity added
in ClientHello parsing.
I'll be really happy to formalize this proposal in a pull request, or to
clarify any unclear point, but I wanted to gather some opinions on the
topic before going further.
--
Arnaud
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
