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

[David Benjamin <[e-mail]>]

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