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

[Eric Rescorla]

On Fri, Mar 2, 2018 at 12:21 AM, Nikos Mavrogiannopoulos 
wrote:

> On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper 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.
>
> I understand that this is an interpretation that makes more sense and
> aligns with the -21 behavior, but I do not think that this is what this
> text literally says.  Both Eric in his previous email and another
> engineer I've discussed the issue seem to agree that the intention is
> to use the new mechanism for all negotiations. You disagree on that,
> and it thus apparent that this text needs clarification.
>

I don't think that's what I meant. I agree with David that if you send
ServerHello.supported_versions it ought not to contain TLS 1.2 or below.

I missed this in -25, but I have a PR up for it now, so if this looks OK,
I'll merge and spin -26. See:
https://github.com/tlswg/tls13-spec/pull/1163

-Ekr


> The text was written for -21 version which didn't have the server-side
> part of the extension, and the flow was natural for pre-TLS1.3
> versions. When the change was done in -22 to include the server-side of
> the extension, this ambiguity (in your view) and complicated side-
> effect (in my view) was introduced.
>
> 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

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

[Nikos Mavrogiannopoulos]

On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper 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.

I understand that this is an interpretation that makes more sense and
aligns with the -21 behavior, but I do not think that this is what this
text literally says.  Both Eric in his previous email and another
engineer I've discussed the issue seem to agree that the intention is
to use the new mechanism for all negotiations. You disagree on that,
and it thus apparent that this text needs clarification.

The text was written for -21 version which didn't have the server-side
part of the extension, and the flow was natural for pre-TLS1.3
versions. When the change was done in -22 to include the server-side of
the extension, this ambiguity (in your view) and complicated side-
effect (in my view) was introduced.

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Thu, Mar 1, 2018 at 10:42 AM, David Benjamin 
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 
> 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
>>  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
>>
>> ___
>> 

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

[David Benjamin]

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

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

[David A. Cooper]

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

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

[Eric Rescorla]

On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos 
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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nikos Mavrogiannopoulos]

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