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

[Yuhong Bao <[e-mail]>]

Of course, the arms race with middleboxes was what added the complexity in the first place.

________________________________________
From: TLS <[e-mail]> on behalf of David Benjamin <[e-mail]>
Sent: Thursday, March 1, 2018 10:42:55 AM
To: David A. Cooper
Cc: [e-mail]
Subject: Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

FWIW, this was BoringSSL's interpretation as well. We don't consider supported_versions an acceptable TLS 1.2 (or earlier) ServerHello extension. I generally agree that we shouldn't add new unnecessary combinations.

(TBH, I don't even consider the ability to advertise TLS 1.3 and TLS 1.1 on the client side to be an especially valuable feature, but I suppose that falls out naturally enough.)

David

On Thu, Mar 1, 2018 at 10:49 AM David A. Cooper <[e-mail]<mailto:[e-mail]>> 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.

On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos
<[e-mail]<mailto:[e-mail]>> wrote:

> The TLS draft after version -21 requires TLS1.3 servers to negotiate
> pre-TLS1.3 versions with a new, mechanism. The document states:
>
>    "If this extension is present, servers MUST ignore the
>    ClientHello.legacy_version value and MUST use only the
>    "supported_versions" extension to determine client preferences."
>
> ...
>
>    "Note that this mechanism makes it possible to negotiate a
>    version prior to TLS 1.2 if one side supports a sparse range."
>
>
> At this point, a server receiving a supported_versions extension which
> contains the single value 'TLS 1.0' has to follow the draft's
> recommendations and do:
>
>   1. It MUST set the ServerHello.legacy_version field to 0x0303
>      (TLS 1.2).
>   2. On the serverHello extensions include a supported_versions
>      extension and advertise TLS1.0
>
> That modifies the way TLS 1.1  or TLS 1.0 are negotiated, possibly
> introducing new issues with middle-boxes which see TLS1.2 in the
> ServerHello but TLS1.0 anywhere else. That is also a quite impossible
> code path (why would an implementation negotiate TLS1.0 using a TLS1.3
> mechanism?). It is however anticipated to be used for that purpose as
> this draft mentions:
>
>    "Servers should be prepared to receive ClientHellos that include
>     this extension but do not include 0x0304 in the list of versions."
>
> Irrespective to any middle-box issues, I believe impossible code paths
> allowed by the protocol are more likely to cause problems than solve
> any, because they are often not tested, and provide attackers with
> additional tools to manipulate implementations.
>
> My recommendation to address that would to either ignore that extension
> if pre-TLS1.2 is negotiated, or revert to -21 draft behavior for pre-
> TLS1.3 protocol negotiation. That is, the server MUST not send the
> supported_versions extension if a pre-TLS1.3 protocol is to be
> negotiated. The first case ensures that there is a single way to
> negotiate TLS1.x, where x<3, and the second that the clientHello
> extension is only used informatively.
>
> regards,
> Nikos

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls