Re: [TLS] TLS 1.3 - Support for compression to be removed

[Martin Rex]

Eric Rescorla wrote:
> 
> That is what the document says:
> "Versions of TLS before 1.3 supported compression and the list of
> compression methods was supplied in this field. For any TLS 1.3
> ClientHello, this field MUST contain only the ?null? compression method
> with the code point of 0. If a TLS 1.3 ClientHello is received with any
> other value in this field, the server MUST generate a fatal
> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2 or
> prior ClientHellos which contain other compression methods and MUST follow
> the procedures for the appropriate prior version of TLS."

The quoted wording calls for a fatal handshake failure when ClientHello
offers

  TLSv1.2+compression  _or_  TLSv1.3

while at the same time the last requirement asserts that a ClientHello with

  TLSv1.2+compression

is perfectly OK.  To me, this looks quite odd.


If you want compression removed from TLSv1.3, how about something like this:


 "Versions of TLS before 1.3 supported compression and the list of
 compression methods was supplied in this field.
  All TLS protocol
 versions require the "null" compression method MUST be included/present
 in the compression_methods list of ClientHello.  A TLSv1.3 server that
 is offered and selects/negotiates protocol version TLSv1.3, MUST select
 the "null" compression method, and MUST ignore all other compression
 methods that might appear in the compression_methods list of ClientHello.


Btw. for the last requirement, I would appreciate an additional recommendation
for a configuration option to disable compression, maybe something like

 This document does not impose restrictions on the use of compression
 with TLS protocol versions prior to TLSv1.3.  However, it is RECOMMENDED
 that implementations which support compression provide a configuration
 option allowing consumers to disable the use of compression in TLS.


-Martin

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Dave Garrett]

On Wednesday, October 07, 2015 03:51:57 pm Martin Rex wrote:
>  However, it is RECOMMENDED
>  that implementations which support compression provide a configuration
>  option allowing consumers to disable the use of compression in TLS.

Risky features like compression should be off by default.


Dave

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Eric Rescorla]

On Wed, Oct 7, 2015 at 9:51 PM, Martin Rex  wrote:

> Eric Rescorla wrote:
> >
> > That is what the document says:
> > "Versions of TLS before 1.3 supported compression and the list of
> > compression methods was supplied in this field. For any TLS 1.3
> > ClientHello, this field MUST contain only the ?null? compression method
> > with the code point of 0. If a TLS 1.3 ClientHello is received with any
> > other value in this field, the server MUST generate a fatal
> > ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2
> or
> > prior ClientHellos which contain other compression methods and MUST
> follow
> > the procedures for the appropriate prior version of TLS."
>
> The quoted wording calls for a fatal handshake failure when ClientHello
> offers
>
>   TLSv1.2+compression  _or_  TLSv1.3
>
> while at the same time the last requirement asserts that a ClientHello with
>
>   TLSv1.2+compression
>
> is perfectly OK.  To me, this looks quite odd.
>

That's not how I read this text.

Rather, I read it as:
If ClientHelloVersion >= TLS 1.3
   then the compression field must be empty
else:
   the compression field is dictated by other versions

This doesn't seem inconsistent to me. If you still think that the paragraph
reads differently, can you help me by diagramming it?



> If you want compression removed from TLSv1.3, how about something like
> this:
>
>
>  "Versions of TLS before 1.3 supported compression and the list of
>  compression methods was supplied in this field.
>   All TLS protocol
>  versions require the "null" compression method MUST be included/present
>  in the compression_methods list of ClientHello.  A TLSv1.3 server that
>  is offered and selects/negotiates protocol version TLSv1.3, MUST select
>  the "null" compression method, and MUST ignore all other compression
>  methods that might appear in the compression_methods list of ClientHello.
>
>
> Btw. for the last requirement, I would appreciate an additional
> recommendation
> for a configuration option to disable compression, maybe something like
>
>  This document does not impose restrictions on the use of compression
>  with TLS protocol versions prior to TLSv1.3.  However, it is RECOMMENDED
>  that implementations which support compression provide a configuration
>  option allowing consumers to disable the use of compression in TLS.
>
>
> -Martin
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Martin Rex]

Eric Rescorla wrote:
> Martin Rex  wrote:
>> Eric Rescorla wrote:
>>>
>>> That is what the document says:
>>> "Versions of TLS before 1.3 supported compression and the list of
>>> compression methods was supplied in this field. For any TLS 1.3
>>> ClientHello, this field MUST contain only the ?null? compression method
>>> with the code point of 0. If a TLS 1.3 ClientHello is received with any
>>> other value in this field, the server MUST generate a fatal
>>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2
>>> or prior ClientHellos which contain other compression methods and MUST
>>> follow the procedures for the appropriate prior version of TLS."
>>
>> The quoted wording calls for a fatal handshake failure when ClientHello
>> offers
>>
>>   TLSv1.2+compression  _or_  TLSv1.3
>>
>> while at the same time the last requirement asserts that a ClientHello with
>>
>>   TLSv1.2+compression
>>
>> is perfectly OK.  To me, this looks quite odd.
> 
> That's not how I read this text.
> 
> Rather, I read it as:
> If ClientHelloVersion >= TLS 1.3
>then the compression field must be empty
> else:
>the compression field is dictated by other versions
> 
> This doesn't seem inconsistent to me. If you still think that the paragraph
> reads differently, can you help me by diagramming it?

What you describe would be considerable worse that what I understood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally
invalid for a TLSv1.2 server.

   https://tools.ietf.org/html/rfc5246#page-42

   compression_methods
  This is a list of the compression methods supported by the client,
  sorted by client preference.  If the session_id field is not empty
  (implying a session resumption request), it MUST include the

Dierks & Rescorla   Standards Track[Page 41]
 
RFC 5246  TLSAugust 2008

*>compression_method from that session.  This vector MUST contain,
*>and all implementations MUST support, CompressionMethod.null.
  Thus, a client and server will always be able to agree on a
  compression method.

-Martin

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Eric Rescorla]

On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex  wrote:

> Eric Rescorla wrote:
> > Martin Rex  wrote:
> >> Eric Rescorla wrote:
> >>>
> >>> That is what the document says:
> >>> "Versions of TLS before 1.3 supported compression and the list of
> >>> compression methods was supplied in this field. For any TLS 1.3
> >>> ClientHello, this field MUST contain only the ?null? compression method
> >>> with the code point of 0. If a TLS 1.3 ClientHello is received with any
> >>> other value in this field, the server MUST generate a fatal
> >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS
> 1.2
> >>> or prior ClientHellos which contain other compression methods and MUST
> >>> follow the procedures for the appropriate prior version of TLS."
> >>
> >> The quoted wording calls for a fatal handshake failure when ClientHello
> >> offers
> >>
> >>   TLSv1.2+compression  _or_  TLSv1.3
> >>
> >> while at the same time the last requirement asserts that a ClientHello
> with
> >>
> >>   TLSv1.2+compression
> >>
> >> is perfectly OK.  To me, this looks quite odd.
> >
> > That's not how I read this text.
> >
> > Rather, I read it as:
> > If ClientHelloVersion >= TLS 1.3
> >then the compression field must be empty
> > else:
> >the compression field is dictated by other versions
> >
> > This doesn't seem inconsistent to me. If you still think that the
> paragraph
> > reads differently, can you help me by diagramming it?
>
> What you describe would be considerable worse that what I understood,
> because it would mean that a TLSv1.3 ClientHello will be unconditionally
> invalid for a TLSv1.2 server.
>
>https://tools.ietf.org/html/rfc5246#page-42
>
>compression_methods
>   This is a list of the compression methods supported by the client,
>   sorted by client preference.  If the session_id field is not empty
>   (implying a session resumption request), it MUST include the
>
> Dierks & Rescorla   Standards Track[Page 41]
>
> RFC 5246  TLSAugust 2008
>
> *>compression_method from that session.  This vector MUST contain,
> *>and all implementations MUST support, CompressionMethod.null.
>   Thus, a client and server will always be able to agree on a
>   compression method.


Sorry, I spoke carelessly. It must contain solely the null method.

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Short, Todd]

However, for those ClientHello’s that support older versions, the 
compression_method field may contain other values. This means that if a TLSv1.3 
client happened to support compression for TLSv1.2, it would be unable to 
negotiate that via a single ClientHello. There’s no way to attempt to negotiate 
TLSv1.2+compression and TLSv1.3+no-compression in a single ClientHello.

In effect, the document is stating that a TLSv1.3 client MUST NOT support 
compression, regardless of the protocol version that may be negotiated.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 7, 2015, at 5:15 PM, Eric Rescorla mailto:e...@rtfm.com>> 
wrote:



On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex mailto:m...@sap.com>> 
wrote:
Eric Rescorla wrote:
> Martin Rex mailto:m...@sap.com>> wrote:
>> Eric Rescorla wrote:
>>>
>>> That is what the document says:
>>> "Versions of TLS before 1.3 supported compression and the list of
>>> compression methods was supplied in this field. For any TLS 1.3
>>> ClientHello, this field MUST contain only the ?null? compression method
>>> with the code point of 0. If a TLS 1.3 ClientHello is received with any
>>> other value in this field, the server MUST generate a fatal
>>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2
>>> or prior ClientHellos which contain other compression methods and MUST
>>> follow the procedures for the appropriate prior version of TLS."
>>
>> The quoted wording calls for a fatal handshake failure when ClientHello
>> offers
>>
>>   TLSv1.2+compression  _or_  TLSv1.3
>>
>> while at the same time the last requirement asserts that a ClientHello with
>>
>>   TLSv1.2+compression
>>
>> is perfectly OK.  To me, this looks quite odd.
>
> That's not how I read this text.
>
> Rather, I read it as:
> If ClientHelloVersion >= TLS 1.3
>then the compression field must be empty
> else:
>the compression field is dictated by other versions
>
> This doesn't seem inconsistent to me. If you still think that the paragraph
> reads differently, can you help me by diagramming it?

What you describe would be considerable worse that what I understood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally
invalid for a TLSv1.2 server.

   
https://tools.ietf.org/html/rfc5246#page-42

   compression_methods
  This is a list of the compression methods supported by the client,
  sorted by client preference.  If the session_id field is not empty
  (implying a session resumption request), it MUST include the

Dierks & Rescorla   Standards Track[Page 41]

RFC 5246  TLSAugust 2008

*>compression_method from that session.  This vector MUST contain,
*>and all implementations MUST support, CompressionMethod.null.
  Thus, a client and server will always be able to agree on a
  compression method.

Sorry, I spoke carelessly. It must contain solely the null method.

-Ekr

___
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] TLS 1.3 - Support for compression to be removed

[Geoffrey Keating]

"Short, Todd"  writes:

> In effect, the document is stating that a TLSv1.3 client MUST NOT
> support compression, regardless of the protocol version that may be
> negotiated.

I believe that is the intent, yes.

I support both the current wording in draft 09 (no compression for
clients or servers, reject ClientHellos that allow compression and TLS
1.3) and the intent as described above.

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Eric Rescorla]

On Wed, Oct 7, 2015 at 11:28 PM, Short, Todd  wrote:

> However, for those ClientHello’s that support older versions, the
> compression_method field may contain other values. This means that if a
> TLSv1.3 client happened to support compression for TLSv1.2, it would be
> unable to negotiate that via a single ClientHello. There’s no way to
> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a
> single ClientHello.
>
> In effect, the document is stating that a TLSv1.3 client MUST NOT support
> compression, regardless of the protocol version that may be negotiated.
>

Yes, this is what I believe it says and what I believe the WG had consensus
on, the reasoning being that we really wished to just remove the feature
entirely. If the chairs declare consensus on something else, I will of
course edit
it to say something else.

-Ekr

--
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 7, 2015, at 5:15 PM, Eric Rescorla  wrote:
>
>
>
> On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex  wrote:
>
>> Eric Rescorla wrote:
>> > Martin Rex  wrote:
>> >> Eric Rescorla wrote:
>> >>>
>> >>> That is what the document says:
>> >>> "Versions of TLS before 1.3 supported compression and the list of
>> >>> compression methods was supplied in this field. For any TLS 1.3
>> >>> ClientHello, this field MUST contain only the ?null? compression
>> method
>> >>> with the code point of 0. If a TLS 1.3 ClientHello is received with
>> any
>> >>> other value in this field, the server MUST generate a fatal
>> >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS
>> 1.2
>> >>> or prior ClientHellos which contain other compression methods and MUST
>> >>> follow the procedures for the appropriate prior version of TLS."
>> >>
>> >> The quoted wording calls for a fatal handshake failure when ClientHello
>> >> offers
>> >>
>> >>   TLSv1.2+compression  _or_  TLSv1.3
>> >>
>> >> while at the same time the last requirement asserts that a ClientHello
>> with
>> >>
>> >>   TLSv1.2+compression
>> >>
>> >> is perfectly OK.  To me, this looks quite odd.
>> >
>> > That's not how I read this text.
>> >
>> > Rather, I read it as:
>> > If ClientHelloVersion >= TLS 1.3
>> >then the compression field must be empty
>> > else:
>> >the compression field is dictated by other versions
>> >
>> > This doesn't seem inconsistent to me. If you still think that the
>> paragraph
>> > reads differently, can you help me by diagramming it?
>>
>> What you describe would be considerable worse that what I understood,
>> because it would mean that a TLSv1.3 ClientHello will be unconditionally
>> invalid for a TLSv1.2 server.
>>
>>https://tools.ietf.org/html/rfc5246#page-42
>> 
>>
>>compression_methods
>>   This is a list of the compression methods supported by the client,
>>   sorted by client preference.  If the session_id field is not empty
>>   (implying a session resumption request), it MUST include the
>>
>> Dierks & Rescorla   Standards Track[Page 41]
>>
>> RFC 5246  TLSAugust 2008
>>
>> *>compression_method from that session.  This vector MUST contain,
>> *>and all implementations MUST support, CompressionMethod.null.
>>   Thus, a client and server will always be able to agree on a
>>   compression method.
>
>
> Sorry, I spoke carelessly. It must contain solely the null method.
>
> -Ekr
>
> ___
> 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] TLS 1.3 - Support for compression to be removed

[Bill Frantz]

On 10/8/15 at 9:43 PM, e...@rtfm.com (Eric Rescorla) wrote:


Yes, this is what I believe it says and what I believe the WG had consensus
on, the reasoning being that we really wished to just remove the feature
entirely. If the chairs declare consensus on something else, I will of
course edit
it to say something else.


I would love to support compression, but I don't hear any of the 
proponents suggesting a way to support compression that is 
immune to the the attacks that have already been fielded. With 
nothing safe on the table, I think compression has to be kicked 
up a layer.


It is possible to think of a parallel layer to TLS which only 
does compression and offers no secrecy features. This facility 
may solve the NNTP problem, but I am not qualified to say 
whether it can solve that problem or not. In any case, such a 
facility  may have many features in common with TLS, including a 
compatible initial negotiation, but it would not be a privacy 
protocol. It could include integrity.


Cheers - Bill

---
Bill Frantz| Truth and love must prevail  | Periwinkle
(408)356-8506  | over lies and hate.  | 16345 
Englewood Ave
www.pwpconsult.com |   - Vaclav Havel | Los Gatos, 
CA 95032


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