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

[Eric Rescorla <[e-mail]>]

On Thu, Mar 1, 2018 at 10:42 AM, David Benjamin <[e-mail]>
wrote:

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

So, I think the key point here is that if you receive SH with SH < TLS
1.3,then you should abort, not ignore it.

-Ekr

(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]>
> 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]> 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]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>