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 <david.coo...@nist.gov> 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 > <n...@redhat.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
