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

[[e-mail] (Martin Rex)]

Eric Rescorla wrote:
> On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich <[e-mail]> wrote:
>>
>>> 1) We know CRIME threat, but it can not be risk for everyone.
>>> e.g., CVSS v2 Base Score: 2.6 (LOW)
>>
>> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called
>> it 7.5
>>
>>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
>>
>> They are equivalent.  If you use AES-GCM and ECDHE, and you don't need
>> 0RTT, then there is no compelling reason to use TLS 1.3.
> 
> 
> I don't want to take a position on what's compelling or not, but there are
> a number of other reasons to use TLS 1.3, including support for
>   real padding,
>   encrypted content types
>   privacy for client authentication, etc.

privacy for client authentication is the only real benefit on this list of 3.

The value of real padding is highly dependent of whether and how it
will actually get used, and is far from automatic.
Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2
would be trivial, and work fine with TLSv1.2 AEAD.

encrypted content types looks like lame duck with zero value to me.

"Is not readily distinguishable by existing deep packet inspection (DPI)
filter types" is pretty much the only thing--and adjusting DPI will be
far from rocket science.

Trying to make a single bit of information stick out less prominently
will only create a false sense of security whenever that bit of information
can be trivially detected from the traffic pattern.

But the collateral damage is that you break stuff that feeds on the
outer record layer structure and state, which can easily push adoption
of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the
15-years-spec-to-marginal-use marginal use seen with IPv6.


-Martin