[TLS] TLS 1.3 supported versions and downgrade protection

[Daniel Van Geest <[e-mail]>]

Hi all,

I think there might be ambiguity or an interoperability issue with the TLS 1.3 ServerHello Random value downgrade protection and some (possibly?) legitimate negotiation of TLS 1.2 using the supported_versions extension.  Looking through RFC 8446 and the mail archives I don’t see anything that addresses this, maybe I’ve missed something?

RFC 8446 Section 4.1.3:

   TLS 1.3 has a downgrade protection mechanism embedded in the server's
   random value.  TLS 1.3 servers which negotiate TLS 1.2 or below in
   response to a ClientHello MUST set the last 8 bytes of their Random
   value specially in their ServerHello.

   If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of
   their Random value to the bytes:

     44 4F 57 4E 47 52 44 01

   If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2
   servers SHOULD, set the last 8 bytes of their ServerHello.Random
   value to the bytes:

     44 4F 57 4E 47 52 44 00

   TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below
   MUST check that the last 8 bytes are not equal to either of these
   values.  TLS 1.2 clients SHOULD also check that the last 8 bytes are
   not equal to the second value if the ServerHello indicates TLS 1.1 or
   below.  If a match is found, the client MUST abort the handshake with
   an "illegal_parameter" alert.

So whenever a TLS 1.3-capable server negotiates a TLS 1.2 or lower session it MUST set the appropriate Random values.

And a TLS 1.3 client MUST check for these values and abort if found. Future TLS versions aren’t mentioned so perhaps one of the use cases I’ll mention below is not a concern until the next version is defined and the behavior can be adjusted then.

Consider the potential cases for the ClientHello supported_versions values:


  1.  supported_versions = { 0x0305 (TLS 1.4), 0x0303 (TLS 1.2) }
Okay, TLS 1.4 doesn’t exist so maybe this can be addressed in the future.  If the server supports TLS 1.2 and TLS 1.3, it will negotiate TLS 1.2 and add the TLS 1.2 downgrade protection Random value.  The Client will see the TLS 1.2 version, check the downgrade protection and abort the connection.  But this is not a downgrade issue, this is the only mutually acceptable TLS version.

  2.  supported_versions = { 0x0303 (TLS 1.2), 0x0304 (TLS 1.3) }
The supported_versions list is in order of client preference, but it’s not required that the server respect the preference.  I’ve seen implementations which respect the client’s preference and ones which pick the highest mutually acceptable version.  If a server supports TLS 1.2 and TLS 1.3 and respects the client’s preference it will negotiate TLS 1.2 and add the downgrade protection random value.  The client would then abort the connection even though this would seem to be a legitimate non-downgrade situation  Or can we wave our hands at this and say if a client doesn’t prefer TLS 1.3 above TLS 1.2 then it’s not really a true Scotsman TLS 1.3 client and those MUSTs don’t really apply to it?.

And so, are these legitimate cases which should be addressed?

Thanks,
Daniel Van Geest