Re: [TLS] TLS 1.3 supported versions and downgrade protection

[Benjamin Kaduk <[e-mail]>]

On Thu, Dec 05, 2019 at 05:30:10PM +0000, Daniel Van Geest wrote:
> 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.

This is analogous to the case of wanting to support TLS 1.0 and 1.2 but not 1.1, which did (IIRC) get a little bit of discussion including from Andrei Popov.  My recollection is that we didn't really feel a need to support "gaps" in supported versions for this downgrade-protection scheme.

>   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?.

I had forgotten that we implied a potential for client preference of supported versions.  We could perhaps debate whether it's "legitimate" for a server to prefer 1.2 over 1.3, but I think it's clear that (assuming the negotiation is protected by a full transcript hash, as in 1.3 or 1.2 with extended master secret) a server negotiating 1.2 in this case should not apply the downgrade-protection scheme.

-Ben