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

[Eric Rescorla <[e-mail]>]

On Wed, Oct 7, 2015 at 11:28 PM, Short, Todd <[e-mail]> 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
> // [e-mail]
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 7, 2015, at 5:15 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex <[e-mail]> wrote:
>
>> Eric Rescorla wrote:
>> > Martin Rex <[e-mail]> 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5246-23page-2D42&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=IxUTnzF6SN6y6C4zTXXfgQmiV1FojXWtLZ0S8hS5eGY&s=Uu3NPBs1t52N_fGVGPqXazTAStG7cPUeCfNh6eCTtkk&e=>
>>
>>    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                          TLS                        August 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>