Re: [TLS] TLS 1.3 - Support for compression to be removed
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
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Sat, Oct 03, 2015 at 12:02:38PM -0400, Daniel Kahn Gillmor wrote: > On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote: > > > 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. I personally would expect that anything that would be broken by content type encryption is already broken by fixing the handshake (it has number of known flaws). That version number field that has absolutely no use in encrypted records is still there... For compatiblity. Also, new user protocols (like TLS) are much much easier to deploy than new addressing protocols (like IPv6). And the stuff that breaks... Probably some badly done "middleware" in "enterprise" environment. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On 2015/10/02, at 22:59, Roland Zink wrote: > Browsers are not a concern as they already have their own comp/decomp codes. > HTTP/1 can compress content (Content-encoding and transfer-encoding) and > HTTP2 has additional header compression. > > Regards, > Roland > I see, but contrary, tls is only for browser? And more, if you kick out comp/decomp from tls, can we be safer when we use tls? If you know the paper, please teach me. Or, rfc or good teacher should notify us, "When you use TLSv1.3, you never use compression, sorry!" I know it may be out scope, but we have to estimate the risk. regards, > > Am 02.10.2015 um 15:08 schrieb takamichi saito: >>> Do we know how many protocols currently suffer from CRIME? >>> >>> >>> Maybe a best practice could be suggested by UTA for the implementation of >>> TLS in software, to disable compression if vulnerable. And for the others, >>> to implement a way to enable/disable compression in case one day a >>> vulnerability is found. >> I agree. >> >> Again, >> >> 1) We know CRIME threat, but it can not be risk for everyone. >> e.g., CVSS v2 Base Score: 2.6 (LOW) >> >> 2) If we need to have comp/decomp in an application layer, >> clients such like browser need their own comp/decomp codes. >> >> 3) If there is no comp in tls1.3, some people may continue to use tls1.2. >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >> >> That's why we explore the way to keep compression in TLSv1.3. >> How about making an option only in server-side? >> The spec has the compression but default is off, and also provides the >> suggestion. >> >> >>> -- >>> Julien ÉLIE >>> >>> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. » >>> >>> ___ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> ;; takamixhi saito >> c2xhYWlidHNvcw >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ;; takamixhi saito ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On 2015/10/03, at 0:24, Salz, Rich 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 > We know it, but one of indicators. How can you say the dangerous or risk instead of it? My point is, CRIME is risk for every case? even when we have option in tls1.3, in case that default is off. >> 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. > If so, some people can skip tls1.3. ;; takamixhi saito ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Sat, Oct 3, 2015 at 3:36 PM, takamichi saito wrote: > > On 2015/10/02, at 22:59, Roland Zink wrote: > > > Browsers are not a concern as they already have their own comp/decomp > codes. HTTP/1 can compress content (Content-encoding and transfer-encoding) > and HTTP2 has additional header compression. > > > > Regards, > > Roland > > > > I see, > but contrary, > tls is only for browser? > > And more, > if you kick out comp/decomp from tls, > can we be safer when we use tls? > If you know the paper, please teach me. > > Or, rfc or good teacher should notify us, > "When you use TLSv1.3, you never use compression, sorry!" > 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." -Ekr > I know it may be out scope, > but we have to estimate the risk. > > regards, > > > > > > Am 02.10.2015 um 15:08 schrieb takamichi saito: > >>> Do we know how many protocols currently suffer from CRIME? > >>> > >>> > >>> Maybe a best practice could be suggested by UTA for the implementation > of TLS in software, to disable compression if vulnerable. And for the > others, to implement a way to enable/disable compression in case one day a > vulnerability is found. > >> I agree. > >> > >> Again, > >> > >> 1) We know CRIME threat, but it can not be risk for everyone. > >> e.g., CVSS v2 Base Score: 2.6 (LOW) > >> > >> 2) If we need to have comp/decomp in an application layer, > >> clients such like browser need their own comp/decomp codes. > >> > >> 3) If there is no comp in tls1.3, some people may continue to use > tls1.2. > >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > >> > >> That's why we explore the way to keep compression in TLSv1.3. > >> How about making an option only in server-side? > >> The spec has the compression but default is off, and also provides the > suggestion. > >> > >> > >>> -- > >>> Julien ÉLIE > >>> > >>> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. » > >>> > >>> ___ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >> ;; takamixhi saito > >> c2xhYWlidHNvcw > >> > >> ___ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > ;; takamixhi saito > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
> On Oct 4, 2015, at 1:44 AM, takamichi saito wrote: > > > On 2015/10/03, at 0:24, Salz, Rich 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 >> > > We know it, but one of indicators. > How can you say the dangerous or risk instead of it? > My point is, CRIME is risk for every case? I don’t know. Probably not. But consider that we had been using HTTP with TLS for over 15 years before we found out about CRIME. It’s a subtle attack that relies on specific structures in HTTP and the peculiar way that browsers allow a script from one site to issue requests on behalf of another site. But still, it took researches all these years to find it. There are many lessons to be learned from this: that a bearer token that is repeated many times is not a good idea; that the trust model in the web is not great; but also that blindly compressing content with no regard to its structure and sources is dangerous and reveals information about the cleartext. A security protocol should not do that. An even more executive-level lesson might be that security layers should not provide non-security services, but that is not really convincing because if there was a separate compression layer that you could compose with the security layer in TLS, CRIME would still be possible. To compress HTTP without the danger of CRIME you need to either not compress header fields with sensitive information, not compress header fields that might be controlled by an attacker, or at least delegate those to a separate compression state. That is not something that any transport layer shim can provide. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
