Re: draft-ietf-tls-tls13-24 supported_versions complexity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx> 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?).

The text you quote explains how this can happen:
- A supports TLS 1.1 and TLS 1.3 draft X
- B supports TLS 1.1 and TLS 1.3 draft Y

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

It's been a while, but I believe this text was actually put in to allow for
the case that clients support TLS 1.3 draft versions but not TLS 1.3 RFC.


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.

I'm not in favor of either of these changes at this time. IMO it's more
straightforward to have an immediate branch on the presence of the
extension and then use only that.

-Ekr
 



regards,
Nikos



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux