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

Hi all, > If compression is so important to NNTP, they should add first-class support. Period. They should not be relying on a poorly conceived feature which has been repeatedly demonstrated to introduce vulnerabilities in what is supposed to be a *security protocol* just because they don't wan

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

> 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. > I see, but contrary, tls is only for browser? And more, if you kick out comp/decomp from

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

2015/10/03 0:24、Salz, Rich のメッセージ: > >> 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 dangerou

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

Watson Ladd wrote: > > Why is it important that clients be permitted to signal support for > compression and TLS 1.3 conditionally? Remember, we also want to phase > out the use of compression in TLS 1.2. compression in TLS is *NOT* generally bad, and not generally a problem. It may be a problem

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

Joseph Salowey wrote: > > The chairs have read through this thread and do not see any new information > that would cause the working group to reconsider the decision to remove > compression from TLS 1.3. I am (and I was) perfectly fine with removing compression from TLSv1.3. (btw. our own implemen

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

The chairs have read through this thread and do not see any new information that would cause the working group to reconsider the decision to remove compression from TLS 1.3. Discussions about clarifying the language and intent of the document are OK. Thanks, J&S On Thu, Oct 8, 2015 at 6:42 PM,

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

On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Short, Todd 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 compre

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

Eric specifically clarified it: On Oct 7, 2015, at 5:15 PM, Eric Rescorla mailto:e...@rtfm.com>> 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

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

Eric Rescorla wrote: > Short, Todd 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

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

On 10/8/15 at 9:43 PM, e...@rtfm.com (Eric Rescorla) wrote: 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 t

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

On Wed, Oct 7, 2015 at 11:28 PM, Short, Todd 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 vi

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

"Short, Todd" writes: > In effect, the document is stating that a TLSv1.3 client MUST NOT > support compression, regardless of the protocol version that may be > negotiated. I believe that is the intent, yes. I support both the current wording in draft 09 (no compression for clients or servers,

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

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 negoti

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

On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Martin Rex wrote: > >> Eric Rescorla wrote: > >>> > >>> 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

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

Eric Rescorla wrote: > Martin Rex wrote: >> Eric Rescorla wrote: >>> >>> 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

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

On Wed, Oct 7, 2015 at 9:51 PM, Martin Rex wrote: > Eric Rescorla wrote: > > > > 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

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

On Wednesday, October 07, 2015 03:51:57 pm Martin Rex wrote: > However, it is RECOMMENDED > that implementations which support compression provide a configuration > option allowing consumers to disable the use of compression in TLS. Risky features like compression should be off by default. Da

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

Eric Rescorla wrote: > > 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

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

On Oct 5, 2015, at 5:17 AM, Eric Rescorla wrote: > > The problem is that we don't know how to generically provide compression > safely. To take a concrete example: HTTP2's solution to header compression, > HPACK, is extremely limited compared to a generic compression system > like gzip, LZ77, etc

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

On 4 October 2015 at 21:06, Eric Rescorla wrote: > > Yes, if the attacker can provide their own data, it makes matters worse, > but as the reference I provided indicated, there are potential security > issues even if the attacker is not able to do so, provided that the data > is sufficiently redun

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

On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson wrote: > On 4 October 2015 at 19:26, Eric Rescorla wrote: > > Consider the trivial case of ASCII text. Each character takes up the > > same amount of room, but if you compress (as an intuition pump, > > think of a simple Huffman code), then more com

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

On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton wrote: > On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich wrote: > >> 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

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

> 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

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

On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton wrote: > >> Typically compression is used to lower the overall size of data, > working on > >> a wide class of inputs. In the perceptual coding case the class of > inputs > >> is constrained, and the goal is to keep the data rate constant, not > >> o

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

On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton wrote: > >> Typically compression is used to lower the overall size of data, > working on > >> a wide class of inputs. In the perceptual coding case the class of > inputs > >> is constrained, and the goal is to keep the data rate constant, not > >> o

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

On Sun, Oct 4, 2015 at 4:01 PM, Jeffrey Walton wrote: >>> Typically compression is used to lower the overall size of data, working on >>> a wide class of inputs. In the perceptual coding case the class of inputs >>> is constrained, and the goal is to keep the data rate constant, not >>> optimally

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

On Sunday, October 04, 2015 03:00:33 pm Tony Arcieri wrote: > On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett > wrote: > > I can think of a way to do this, but the people who want compression badly > > probably won't like it due to the need to pad heavily. > > > > 1) Pick a fixed bandwidth > > 2) Co

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

On Sunday, October 04, 2015 02:48:19 pm Jeffrey Walton wrote: > If I am reading things correctly: the group has effectively > encountered a security problem, deemed it to be too hard for them, and > then pushed it into another layer where folks are even less equipped > to deal with it. Is that corr

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

On Sunday, October 04, 2015 02:09:49 pm Tony Arcieri wrote: > If someone has produced a secure system for "compression side-channel > resistant encryption", I haven't seen it. I can think of a way to do this, but the people who want compression badly probably won't like it due to the need to pad

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

On Sunday, October 04, 2015 01:58:09 pm Jeffrey Walton wrote: > Is that necessarily true? It should be apparent by now that the dominant opinion is that compression in TLS is not worth the risk and not worth the time to attempt to deal with here. Whether or not a generic compression algorithm co

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

On Sun, Oct 4, 2015 at 10:58 AM, Jeffrey Walton wrote: > > The takeaway for me is you can't mix compression, any fixed value an > > attacker wishes to learn, and attacker-controlled data, or there will be > a > > compression side-channel. > > Is that necessarily true? > > Deflate violates semanti

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

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

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

On Sat, Oct 3, 2015 at 4:54 PM, Yoav Nir wrote: > 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

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

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 compre

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

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

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-

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 establis

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

> On Oct 2, 2015, at 6:42 PM, Eric Rescorla wrote: > > > > On Fri, Oct 2, 2015 at 8:24 AM, 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

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

Eric Rescorla wrote: > On Fri, Oct 2, 2015 at 8:24 AM, 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 >> >>> Which one is safer,

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

On Fri 2015-10-02 11:24:10 -0400, Salz, Rich wrote: >> 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. ...and you use session-hash, and you either do

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

> I don't think we should be claiming that TLS 1.2 is equivalent to TLS > 1.3 without many more caveats. :) Fair enough. ___ 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 Fri, Oct 2, 2015 at 8:24 AM, 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 > > > Which one is safer, "tls1.2" v.s. "tls1.3 with

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

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

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

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 Am 02.10.2015 um 15:08 schrieb takamichi saito: Do we know how many protocols current

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

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

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

> > This requires new application protocol verbs "STARTCOMPRESSION", > > "STOPCOMPRESSION", and underlying support in the TLS layer. > I wonder if it would have been possible to do this via renegotiation, though > this has overhead. Intriguing, but moot of course, since renegotiation is gone. :

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

On Fri, Sep 25, 2015 at 07:40:05PM +0100, Jeremy Harris wrote: > Why is it not possible for TLS1.3 to provide that same service > combination, but implemented by design in a layered fashion? TLS is correctly agnostic of semantic boundaries, in application data. For this to work, applications wou

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

On 23/09/15 06:55, Tony Arcieri wrote: > They should not be relying on a poorly conceived feature > which has been repeatedly demonstrated to introduce vulnerabilities in what > is supposed to be a *security protocol* just because they don't want to > implement compression themselves. I see peopl

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

Hi Bill, Well, it depends. How much security do people need. In the NNTP case, I can't see a strong argument for confidentiality. There may be a need for compression, which is why I suggested a "TLC" (Transport Level Compression) facility, which is, to the extent possible, API compatible with a

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

Hi Yoav, And you don’t usually need 25 Mbps for NNTP, although the last time I actually used NNTP was over a 56Kbps modem. Yep, accessing text-only newsgroups is fine with a 56Kbps modem, though getting overview data (roughly the headers of the articles) may take time on the "subscription" t

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

On Thu, 2015-09-24 at 10:52 +0300, Yoav Nir wrote: > > On other lists I still see the occasional quip about suffering a > > low > > bandwidth connection. It used to be folks in some European > > countries, > > but most recently I seem to recall South American. (I think we're > > seeing the shift b

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

> On Sep 24, 2015, at 7:40 AM, Jeffrey Walton wrote: > >> I have to wonder if it’s worth it. In the last decade bandwidth has >> increased and prices for networking have gone down much faster than CPU >> speeds. 10 years ago having 1 Mbps at home was the highest-end broadband >> you could ge

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

> I have to wonder if it’s worth it. In the last decade bandwidth has increased > and prices for networking have gone down much faster than CPU speeds. 10 > years ago having 1 Mbps at home was the highest-end broadband you could get. > Now you routinely get 100x that. CPU has increased, but now

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

On 9/23/15 at 4:17 PM, noloa...@gmail.com (Jeffrey Walton) wrote: IMHO, compression adds too many security vulnerabilities to a general purpose secure communication protocol. I think TLS 1.3 is right in eliminating it. It is too big a foot gun. To play devil's advocate: if (1) compression incr

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

> On Sep 23, 2015, at 4:17 PM, Jeffrey Walton wrote: > >> IMHO, compression adds too many security vulnerabilities to a general >> purpose secure communication protocol. I think TLS 1.3 is right in >> eliminating it. It is too big a foot gun. > > To play devil's advocate: if (1) compression inc

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

On 9/22/15 at 11:21 AM, basc...@gmail.com (Tony Arcieri) wrote: On Tue, Sep 22, 2015 at 11:16 AM, Julien ÉLIE wrote: What for protocols that aren't subject to unsafe usage and that were relying on the compression facility provided by TLS? Unconditionally removing TLS compression leads to a re

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

I meant does *NOT* seem. We agree, sorry. On Tue, Sep 22, 2015 at 10:55 PM, Tony Arcieri wrote: > On Tue, Sep 22, 2015 at 8:32 PM, Colm MacCárthaigh > wrote: > >> it doesn't seem too hard. My 2c: even if this were not the case, >> optimizing NNTP in a backwards compatible way does seem like a

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

On Tue, Sep 22, 2015 at 8:32 PM, Colm MacCárthaigh wrote: > it doesn't seem too hard. My 2c: even if this were not the case, > optimizing NNTP in a backwards compatible way does seem like a more > important goal than making transport security as secure as possible by > default. > I don't think I

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

I think there is a compression extension for NNTP: http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html it doesn't seem too hard. My 2c: even if this were not the case, optimizing NNTP in a backwards compatible way does seem like a more important goal than making transport security as s

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

Benjamin Kaduk writes: >Well, this just came across my browser: >http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new- >compression.html There's a million compression algorithms [0] out there, you shouldn't have any problem finding one to fit your needs, and you don't really ne

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

On Tue, Sep 22, 2015 at 02:56:36PM -0400, Jeffrey Walton wrote: > > If compression increases entropy, then one could argue its a desired > service with security benefits. Compression does not change the total amount of entropy. It has the same entropy but in less bits, so you increase the densit

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

On 09/22/2015 02:44 PM, Yoav Nir wrote: >> On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote: >> >> The security community thinks that compression is risky, error-prone, and >> that a security/auth layer is the wrong place to put it. >> >> So far, the only counter-argument has been "if TLS 1.2 has a

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

> On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote: > > The security community thinks that compression is risky, error-prone, and > that a security/auth layer is the wrong place to put it. > > So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to > move to TLS 1.3 without

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

On 22/09/15 19:32, Yoav Nir wrote: > >> On Sep 22, 2015, at 8:35 PM, Stephen Farrell >> wrote: >> >> >> >> On 22/09/15 17:23, Tony Arcieri wrote: >>> But an unsafe feature shouldn't be kept in >>> TLS just because some protocols want to do unsafe things and are too lazy >>> to implement their

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

Hi Rich, The security community thinks that compression is risky, error-prone, and that a security/auth layer is the wrong place to put it. So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression." Is this accurate? Thanks

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

The security community thinks that compression is risky, error-prone, and that a security/auth layer is the wrong place to put it. So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression." Is this accurate? -- Senior Archit

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

Hi Dave, No sane security protocol should allow any mode which is known to be insecure under its common use-case. Then the default in TLS 1.3 could be to not activate compression. TLS 1.2 is technically configurable in a secure manner, but hardly anyone does so correctly. With TLS 1.3, we n

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

> On Sep 22, 2015, at 8:35 PM, Stephen Farrell > wrote: > > > > On 22/09/15 17:23, Tony Arcieri wrote: >> But an unsafe feature shouldn't be kept in >> TLS just because some protocols want to do unsafe things and are too lazy >> to implement their own compression. > > Compression does have i

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

On Tuesday, September 22, 2015 02:16:47 pm Julien ÉLIE wrote: > Regarding vulnerable protocols, clients (and/or servers) could very well > disable compression in TLS. And either never use compression or > implement their own compression, according to their needs. > It is what happened with BEAST

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

Hi Tony, Keeping compression in TLS endorses unsafe usage of a feature known to introduce compression sidechannels. Whether other protocols decide to introduce their own secondary compression layer is their own prerogative. But an unsafe feature shouldn't be kept in TLS just because some protoc

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

On Tue, Sep 22, 2015 at 1:35 PM, Stephen Farrell wrote: > > > On 22/09/15 17:23, Tony Arcieri wrote: >> But an unsafe feature shouldn't be kept in >> TLS just because some protocols want to do unsafe things and are too lazy >> to implement their own compression. > > Compression does have issues cl

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

On 22/09/15 17:23, Tony Arcieri wrote: > But an unsafe feature shouldn't be kept in > TLS just because some protocols want to do unsafe things and are too lazy > to implement their own compression. Compression does have issues clearly, but it's not correct to describe people wanting TLS to compr

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

On Tue, Sep 22, 2015 at 6:23 AM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Also, if compression is moved from TLS to upper layer(s) - how would it > mitigate compression-related attacks? Besides "now it's somebody else's > problem"? This is the wrong way of looking at it. Keepin

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

Hi all, On 22 September 2015 at 15:23, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Also, if compression is moved from TLS to upper layer(s) - how would it > mitigate compression-related attacks? Besides "now it's somebody else's > problem"? > It allows the authors of the layers ab

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

tember 22, 2015 04:07 > To: Julien ÉLIE > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed > > Julien ÉLIE writes: > >> Hi Karthik, >> >>> It may well be true that some (typically unauthenticated) application >>>

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

efsson Sent: Tuesday, September 22, 2015 04:07 To: Julien ÉLIE Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed Julien ÉLIE writes: > Hi Karthik, > >> It may well be true that some (typically unauthenticated) application >> protocols on top of TLS

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

Julien ÉLIE writes: > Hi Karthik, > >> It may well be true that some (typically unauthenticated) application >> protocols on top of TLS can survive TLS compression, but it is >> unlikely. > [...] >> HTTP is a particularly bad case because the attacker can potentially >> inject arbitrary data befo

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

On Sat, Sep 19, 2015 at 12:04 PM, Daniel Kahn Gillmor wrote: > I think we should remove compression and we should also explicitly warn > users of the protocol about the risks of combining compression with TLS. +1 -- Tony Arcieri ___ TLS mailing list

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

On Fri 2015-09-18 15:47:27 -0400, "Salz, Rich" wrote: > Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression > feature you need? What TLS 1.3 feature is compelling here? I think this line of argument is worrisome -- we should try to avoid leaving behind protocols that need TLS, i

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

Hi Geoffrey, I bet other protocols would also need similar new specifications to explain how compression can be enabled. I think that's the idea. TLS compression only works for NNTP because no confidentiality is required. In other protocols, there's at least something (if not everything) whe

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

Hi Karthik, It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, but it is unlikely. [...] HTTP is a particularly bad case because the attacker can potentially inject arbitrary data before (and after) the secret. With NNTP y

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

On Sun, Sep 20, 2015 at 11:02:19AM +0200, Julien ÉLIE wrote: > Though I've read a few pages explaining how CRIME and BEAST attacks work, I > still do not see well how TLS-level compression would make NNTP vulnerable. > Same thing for POP or IMAP I believe. > > The news server does not leak inform

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

> How compression would make NNTP weaker? > (Brute-force attack is still necessary, even with compression enabled.) I don't know, which is why I put a question mark; someone else suggested it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailm

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

Julien, It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, but it is unlikely. You ask a pointed question about AUTHINFO, so just as a fun game, let’s analyze its security: AUTHINFO USER test 381 Enter password AUTHINFO P

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

Hi Watson, Though I've read a few pages explaining how CRIME and BEAST attacks work, I still do not see well how TLS-level compression would make NNTP vulnerable. Same thing for POP or IMAP I believe. The news server does not leak information. The responses are just OK or KO. This analysis w

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

On Sun, Sep 20, 2015 at 5:02 AM, Julien ÉLIE wrote: > Hi Rich, > >> It is widely recognized that in many cases, TLS-level compression is >> flawed (for example NNTP authinfo?). > > > Though I've read a few pages explaining how CRIME and BEAST attacks work, I > still do not see well how TLS-level c

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

Hi Rich, It is widely recognized that in many cases, TLS-level compression is flawed (for example NNTP authinfo?). Though I've read a few pages explaining how CRIME and BEAST attacks work, I still do not see well how TLS-level compression would make NNTP vulnerable. Same thing for POP or IM

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

On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote: > On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote: > > The concern will be when TLS 1.2 is declared "flawed". Maybe one day it > > will > > be considered insecure; and then, compliant TLS implementations won't be > > able t

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

> Well, it is true that NNTP can stay on TLS 1.2. News clients and news servers > can implement TLS 1.2 and use it. > The concern will be when TLS 1.2 is declared "flawed". Maybe one day it will > be considered insecure; and then, compliant TLS implementations won't be > able to use compression

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

Julien ÉLIE writes: > Unless you are speaking of an update of the NNTP protocol to add a new > compression capability (for instance with the use of a new COMPRESS > command with possible arguments), that could be used by clients? > Well, it will require some work to specify it. Not to speak of i

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

Hi Loganaden, If compression is dropped at the TLS layer, you can still do it at the layer above it. Indeed. And, it's probably a better idea to do it in the layer above. Then how will the news server know that the client is compressing data after the use of STARTTLS where a security

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

On Sat, Sep 19, 2015 at 11:46 AM, Kurt Roeckx wrote: > On Thu, Sep 17, 2015 at 01:23:19PM +, Alewa, Christos wrote: > > Since we at HOB, use SSL to maintain long-running VPN connections, might > it be possible to - at least - maintain the status quo of the TLS - > protocol in this aspect, ena

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

On Thu, Sep 17, 2015 at 01:23:19PM +, Alewa, Christos wrote: > Since we at HOB, use SSL to maintain long-running VPN connections, might it > be possible to - at least - maintain the status quo of the TLS - protocol in > this aspect, enabling and disabling compression if needed? If compressio

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

Hi Rich, Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression feature you need? What TLS 1.3 feature is compelling here? Reading latest draft-ietf-tls-rfc5246-bis, I think the relevant paragraph is: compression_methods Versions of TLS before 1.3 supported compressi

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

Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression feature you need? What TLS 1.3 feature is compelling here? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

Hi all, the proposed cease of support for compression in the new TLS 1.3 protocol [...] Since we at HOB, use SSL to maintain long-running VPN connections, might it be possible to - at least - maintain the status quo of the TLS - protocol in this aspect, enabling and disabling compression if ne