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

["Short, Todd" <[e-mail]>]

Eric specifically clarified it:

On Oct 7, 2015, at 5:15 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

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

-Ekr

So the text needs to be corrected to reflect that. This will avoid the backward compatibility issues.

IMHO, the text should also clearly state something along the lines that “A TLSv1.3 client MUST NOT support compression, regardless of the protocol version that may be negotiated.” This reinforces backwards-compatibility via the use of CipherMethod.null, makes it blatantly obvious that compression is not supported, and a TLSv1.3 client is a good citizen in avoiding CRIME-type attacks.

--
-Todd Short
// [e-mail]<mailto:[e-mail]>
// "One if by land, two if by sea, three if by the Internet."

On Oct 8, 2015, at 5:22 PM, Martin Rex <[e-mail]<mailto:[e-mail]>> wrote:

Eric Rescorla wrote:
Short, Todd <[e-mail]<mailto:[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.

Yup, that is the problem with the current text.



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.

The current text is trying to force a specific policy in a fashion
that is in the worst conceivable violation of rfc2119 section 6 that
is possible.

A ClientHello with

   ClientHello.client_version = (3,3)
   ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.


   ClientHello.client_version = (3,4)
   ClientHello.compression_methods = (1,0)

will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
but TLSv1.3 servers that follow the stupid idea will choke and
abort with an "illegal_parameter" alert.

Essentially, the current wording is calling for a newly creating what
must be called a "compression method intolerance" -- but essentially
it is indistinguishable from a "TLS version intolerance"


For a number of years, it seemed to have been consensus in the IETF TLS WG
that TLS version intolerance is an implemenattion defect and a real problem.
It would be sad if the current TLS WG would confirm that recklessly adding
handshake failure causing new intolerances into TLSv1.3 is the new
engeneering approach.



-Martin