On Thu, Mar 1, 2018 at 10:42 AM, David Benjamin <david...@chromium.org> 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 <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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
