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

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote:
> The value of real padding is highly dependent of whether and how it
> will actually get used, and is far from automatic.

Sure, but we have no existing mechanism to do that in TLS 1.2 or
earlier.  We need the mechanism before anyone can establish sensible
policy.  Understanding what policy is sensible is likely to be
endpoint-specific, and is definitely something that needs research.  But
we can't implement any policy at all without having the mechanism in
place.

> Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2
> would be trivial, and work fine with TLSv1.2 AEAD.

"would be trivial" is not "has been specified".  It also requires
negotiation, whereas hopefully in 1.3, we will not need to negotiate
padding.  Furthermore, If you treat padding as a "compression alg" in
1.2, then the folks who started this thread who want 1.2 because of its
support for compression would not be able to use padding in conjunction
with compression (if someone has a use case for such a combination,
which seems counterintuitive at first glance).  So this proposal doesn't
really address the original reason for the suggestion of "stay on 1.2".

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

I beg to differ -- if there is any interleaving of application_data and
other content types, and if records can be arbitrarily-sized, it's not
clear to me how a DPI can distinguish one from the other.  Can you be
more specific?

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

We need to be looking at things the other way around: if there's a
sensible way to leak less metadata, we should be leaking less metadata,
even if there are other ways that the same information can be recovered
by a similar adversary.  "don't fix X because Y has the same problem" is
a great symmetric recipe for not getting anything done.  We should be
saying "we need to fix both X and Y" instead.

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

Can you enumerate the stuff you expect to break from encrypted content
type that will cause a decade-long delay in adoption?  It would be great
to have a list of those things so we can evaluate them.

   --dkg