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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
