Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper wrote:
> 
> I believe you are misinterpreting the text, but agree that it could
> be 
> made more clear.
> 
> Suppose that the ClientHello includes a supported_versions
> extensions 
> that contains two values, TLS 1.4 and TLS 1.0, and the server
> supports 
> TLS 1.3 and below. My interpretation of the current draft is that
> the 
> server MUST use the supported_versions extension to determine the 
> client's preference, but then once deciding to use TLS 1.0 for the 
> connection sends a normal TLS 1.0 ServerHello, with version field set
> to 
> 0x0300 and no supported_versions extension. Note that Section 4.2.1
> says 
> that
> 
>       A server which negotiates TLS 1.3 MUST respond by sending a
>       "supported_versions" extension containing the selected version
>       value (0x0304).
> 
> It says nothing about a server that negotiates an earlier version.
> 
> If my understanding is correct, then I believe the text in Section
> 4.1.3 
> could be made more clear. Draft -21 said that the version field of 
> ServerHello "contains the version of TLS negotiated for this 
> connection." (this is similar to what RFC 5246 said). The current
> draft 
> says:
> 
>        In TLS 1.3, the TLS server indicates its version using the
>        "supported_versions" extension (Section 4.2.1), and the
>        legacy_version field MUST be set to 0x0303, which is the
>        version number for TLS 1.2.
> 
> To be consistent with RFC 5246 and earlier, it seems like the text 
> should say something like:
> 
>        For a TLS 1.3 ServerHello the TLS server indicates its version
>        using the "supported_versions" extension (Section 4.2.1), and
>        the legacy_version field MUST be set to 0x0303, which is the
>        version number for TLS 1.2. For a TLS 1.2 and earlier
> ServerHello
>        the legacy_version field contains the version of TLS
> negotiated
>        for this connection.

I understand that this is an interpretation that makes more sense and
aligns with the -21 behavior, but I do not think that this is what this
text literally says.  Both Eric in his previous email and another
engineer I've discussed the issue seem to agree that the intention is
to use the new mechanism for all negotiations. You disagree on that,
and it thus apparent that this text needs clarification.

The text was written for -21 version which didn't have the server-side
part of the extension, and the flow was natural for pre-TLS1.3
versions. When the change was done in -22 to include the server-side of
the extension, this ambiguity (in your view) and complicated side-
effect (in my view) was introduced.

regards,
Nikos