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

[Julien ÉLIE]

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 want to implement compression themselves.

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.


[Stephen]
Compression does have issues clearly, but it's not correct to
describe people wanting TLS to compress as lazy. They're rather
looking for the same features that TLS has offered for a couple of
decades.


The good news is that the "first-class" NNTP compression support will 
soon be a reality.  We've updated the draft of the COMPRESS command, and 
we hope to publish it as an RFC:

https://tools.ietf.org/html/draft-murchison-nntp-compress-02

Interoperability is proven:  both a news client (flnews) and a news 
server (INN) have implemented it.


As far as security is concerned, authentication MUST be done *before* 
activating the compression layer (in other words, AUTHINFO is no longer 
valid after a successful use of COMPRESS).



Thanks again guys for having put us to work on that NNTP extension!

--
Julien ÉLIE

« Aequum est ut cuius participauit lucrum, participet et damnun. »

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[takamichi saito]

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


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

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

[takamichi saito]

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

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

[Martin Rex]

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 for usage scenarios where attacker-supplied content
and unknown content are mixed prior to compression, and in particular
where an attacker is freely given elaborate control over the behaviour
of one of the endpoints (e.g. SSL-VPNs and Web-Browsers), but there
are many more, perfectly valid usage scenarios, where TLS compression
is in current use, such as copying huge sparse files over a
TLS-protected communication channel.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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 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."
>
> The quoted wording calls for a fatal handshake failure when ClientHello
> offers
>
>   TLSv1.2+compression  _or_  TLSv1.3
>
> while at the same time the last requirement asserts that a ClientHello with
>
>   TLSv1.2+compression
>
> is perfectly OK.  To me, this looks quite odd.
>

That's not how I read this text.

Rather, I read it as:
If ClientHelloVersion >= TLS 1.3
   then the compression field must be empty
else:
   the compression field is dictated by other versions

This doesn't seem inconsistent to me. If you still think that the paragraph
reads differently, can you help me by diagramming it?



> If you want compression removed from TLSv1.3, how about something like
> this:
>
>
>  "Versions of TLS before 1.3 supported compression and the list of
>  compression methods was supplied in this field.
>   All TLS protocol
>  versions require the "null" compression method MUST be included/present
>  in the compression_methods list of ClientHello.  A TLSv1.3 server that
>  is offered and selects/negotiates protocol version TLSv1.3, MUST select
>  the "null" compression method, and MUST ignore all other compression
>  methods that might appear in the compression_methods list of ClientHello.
>
>
> Btw. for the last requirement, I would appreciate an additional
> recommendation
> for a configuration option to disable compression, maybe something like
>
>  This document does not impose restrictions on the use of compression
>  with TLS protocol versions prior to TLSv1.3.  However, it is RECOMMENDED
>  that implementations which support compression provide a configuration
>  option allowing consumers to disable the use of compression in TLS.
>
>
> -Martin
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Short, Todd]

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 negotiate 
TLSv1.2+compression and TLSv1.3+no-compression in a single ClientHello.

In effect, the document is stating that a TLSv1.3 client MUST NOT support 
compression, regardless of the protocol version that may be negotiated.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 7, 2015, at 5:15 PM, Eric Rescorla > 
wrote:



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 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."
>>
>> The quoted wording calls for a fatal handshake failure when ClientHello
>> offers
>>
>>   TLSv1.2+compression  _or_  TLSv1.3
>>
>> while at the same time the last requirement asserts that a ClientHello with
>>
>>   TLSv1.2+compression
>>
>> is perfectly OK.  To me, this looks quite odd.
>
> That's not how I read this text.
>
> Rather, I read it as:
> If ClientHelloVersion >= TLS 1.3
>then the compression field must be empty
> else:
>the compression field is dictated by other versions
>
> This doesn't seem inconsistent to me. If you still think that the paragraph
> reads differently, can you help me by diagramming it?

What you describe would be considerable worse that what I understood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally
invalid for a TLSv1.2 server.

   
https://tools.ietf.org/html/rfc5246#page-42

   compression_methods
  This is a list of the compression methods supported by the client,
  sorted by client preference.  If the session_id field is not empty
  (implying a session resumption request), it MUST include the

Dierks & Rescorla   Standards Track[Page 41]

RFC 5246  TLSAugust 2008

*>compression_method from that session.  This vector MUST contain,
*>and all implementations MUST support, CompressionMethod.null.
  Thus, a client and server will always be able to agree on a
  compression method.

Sorry, I spoke carelessly. It must contain solely the null method.

-Ekr

___
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

[Eric Rescorla]

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 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."
> >>
> >> The quoted wording calls for a fatal handshake failure when ClientHello
> >> offers
> >>
> >>   TLSv1.2+compression  _or_  TLSv1.3
> >>
> >> while at the same time the last requirement asserts that a ClientHello
> with
> >>
> >>   TLSv1.2+compression
> >>
> >> is perfectly OK.  To me, this looks quite odd.
> >
> > That's not how I read this text.
> >
> > Rather, I read it as:
> > If ClientHelloVersion >= TLS 1.3
> >then the compression field must be empty
> > else:
> >the compression field is dictated by other versions
> >
> > This doesn't seem inconsistent to me. If you still think that the
> paragraph
> > reads differently, can you help me by diagramming it?
>
> What you describe would be considerable worse that what I understood,
> because it would mean that a TLSv1.3 ClientHello will be unconditionally
> invalid for a TLSv1.2 server.
>
>https://tools.ietf.org/html/rfc5246#page-42
>
>compression_methods
>   This is a list of the compression methods supported by the client,
>   sorted by client preference.  If the session_id field is not empty
>   (implying a session resumption request), it MUST include the
>
> Dierks & Rescorla   Standards Track[Page 41]
>
> RFC 5246  TLSAugust 2008
>
> *>compression_method from that session.  This vector MUST contain,
> *>and all implementations MUST support, CompressionMethod.null.
>   Thus, a client and server will always be able to agree on a
>   compression method.


Sorry, I spoke carelessly. It must contain solely the null method.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

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? 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."
>>
>> The quoted wording calls for a fatal handshake failure when ClientHello
>> offers
>>
>>   TLSv1.2+compression  _or_  TLSv1.3
>>
>> while at the same time the last requirement asserts that a ClientHello with
>>
>>   TLSv1.2+compression
>>
>> is perfectly OK.  To me, this looks quite odd.
> 
> That's not how I read this text.
> 
> Rather, I read it as:
> If ClientHelloVersion >= TLS 1.3
>then the compression field must be empty
> else:
>the compression field is dictated by other versions
> 
> This doesn't seem inconsistent to me. If you still think that the paragraph
> reads differently, can you help me by diagramming it?

What you describe would be considerable worse that what I understood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally
invalid for a TLSv1.2 server.

   https://tools.ietf.org/html/rfc5246#page-42

   compression_methods
  This is a list of the compression methods supported by the client,
  sorted by client preference.  If the session_id field is not empty
  (implying a session resumption request), it MUST include the

Dierks & Rescorla   Standards Track[Page 41]
 
RFC 5246  TLSAugust 2008

*>compression_method from that session.  This vector MUST contain,
*>and all implementations MUST support, CompressionMethod.null.
  Thus, a client and server will always be able to agree on a
  compression method.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

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.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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 via a single ClientHello. There’s no way to
> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a
> single ClientHello.
>
> In effect, the document is stating that a TLSv1.3 client MUST NOT support
> compression, regardless of the protocol version that may be negotiated.
>

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 to say something else.

-Ekr

--
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 7, 2015, at 5:15 PM, Eric Rescorla  wrote:
>
>
>
> 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 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."
>> >>
>> >> The quoted wording calls for a fatal handshake failure when ClientHello
>> >> offers
>> >>
>> >>   TLSv1.2+compression  _or_  TLSv1.3
>> >>
>> >> while at the same time the last requirement asserts that a ClientHello
>> with
>> >>
>> >>   TLSv1.2+compression
>> >>
>> >> is perfectly OK.  To me, this looks quite odd.
>> >
>> > That's not how I read this text.
>> >
>> > Rather, I read it as:
>> > If ClientHelloVersion >= TLS 1.3
>> >then the compression field must be empty
>> > else:
>> >the compression field is dictated by other versions
>> >
>> > This doesn't seem inconsistent to me. If you still think that the
>> paragraph
>> > reads differently, can you help me by diagramming it?
>>
>> What you describe would be considerable worse that what I understood,
>> because it would mean that a TLSv1.3 ClientHello will be unconditionally
>> invalid for a TLSv1.2 server.
>>
>>https://tools.ietf.org/html/rfc5246#page-42
>> 
>>
>>compression_methods
>>   This is a list of the compression methods supported by the client,
>>   sorted by client preference.  If the session_id field is not empty
>>   (implying a session resumption request), it MUST include the
>>
>> Dierks & Rescorla   Standards Track[Page 41]
>>
>> RFC 5246  TLSAugust 2008
>>
>> *>compression_method from that session.  This vector MUST contain,
>> *>and all implementations MUST support, CompressionMethod.null.
>>   Thus, a client and server will always be able to agree on a
>>   compression method.
>
>
> Sorry, I spoke carelessly. It must contain solely the null method.
>
> -Ekr
>
> ___
> 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

[Martin Thomson]

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


Sometimes, it's OK.  Sometimes, not.  Agreed.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

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 correct?
> 
> I might be missing something, but I don't believe the "problems
> created by compression" have gone away. Rather, they have been moved
> around so the risk remains. The underlying problem still exists
> because the group responsible for providing those security services
> have not addressed them.

TLS & SPDY + HTTP compression was broken due to CRIME. The fix was to disable 
it, and then HTTP/2 introduced HPACK to compress headers safely. Yes, the 
security issue has been moved around, but to a place that can actually fix it 
properly. There is nothing TLS could do to implement a fix like HPACK here. I 
don't claim this is the only way to fix this problem, but it is a 
straightforward one and the one that is being done.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

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 semantic security by allowing the attacker to gain
> information across messages (even though any single message is
> secure). So perhaps its the mode of compression ot the way compression
> was implemented, and not compression itself.


The only property of compression that this class of side-channel attack
relies on is that the compression algorithm produces a smaller output for
message a || a than a || b (where a and b are of identical length), so
really it would seem to be a conceptual problem with mixing compression and
encryption.

If someone has produced a secure system for "compression side-channel
resistant encryption", I haven't seen it.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

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) Compress & encrypt the stream
> > 3) Send the compressed stream at a rate blocked to the cap
> > 4) Whenever below the cap, pad the stream to the cap
> >
> > Maintain a fixed transmission of data per unit time and there's no way to
> > tell the size of anything (even if delivery doesn't match the rate).
> 
> This sounds like Constant Bitrate (CBR) compression, which works for
> encrypted media (e.g. encrypted voice and video), but probably isn't
> particularly useful outside the realm of realtime media. It was a solution
> that seems to work for attacks that could e.g. transcribe encrypted phone
> calls by studying patterns in Variable Bitrate (VBR) compression on speech.
> 
> 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 small.

Yep. You could do this in bursts with different caps each time to get it to 
work with bursty things like HTTP & other general data transfer protocols. 
Without a really good modern compression algorithm, though, it isn't that 
appealing. Once these caveats and tweaks start getting added to the simple 
concept, it starts treading into the territory that is better handled by the 
application protocol that actually *knows what it's sending*. This seems to be 
the logical wall we keep hitting, which is why TLS doesn't seem like the place 
to do this.

Maybe some new transport protocol could be fed information to tell it how to 
handle compression safely, but TLS is not a transport protocol nor a young one 
that can be fundamentally changed to accommodate everything.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

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

1) Pick a fixed bandwidth
2) Compress & encrypt the stream
3) Send the compressed stream at a rate blocked to the cap
4) Whenever below the cap, pad the stream to the cap

Maintain a fixed transmission of data per unit time and there's no way to tell 
the size of anything (even if delivery doesn't match the rate). However, this 
relies on being able to pick a usable fixed bandwidth (in each direction). The 
bandwidth cap size and length of transmission times still gives quite a bit of 
info, e.g. 1GB vs 1KB total is quite telling, but that's true without 
compression.

With a good compression algorithm, the above could probably produce an overall 
more efficient stream rather easily for many things. If your idea of 
compression is to keep using DEFLATE forever, however, you should probably just 
reevaluate what you're doing.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> 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

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

[takamichi saito]

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

[takamichi saito]

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

[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

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

[Roland Zink]

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

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

[Salz, Rich]

> 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

[Martin Rex]

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, "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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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 would need to be able to ask
TLS to enable and disable compression at any time after the handshake,
once some uncompressed or compressed data has gone by.

This requires new application protocol verbs "STARTCOMPRESSION",
"STOPCOMPRESSION", and underlying support in the TLS layer.

A suitable application I/O library that supports pushing and popping
protocol "modules" onto a raw I/O stream, would be a better vehicle
for this than forcing dynamic compression support into TLS.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> > 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. :)  Interesting 
corner-cases to think about:  is compression restarted, or do you preserve all 
state to pick up where you left off (e.g., the zlib dictionary)?  Either either 
one probably has some security issues to think about.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> 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 get. Now you routinely get 100x that. CPU has increased, but 
>> nowhere near that. This makes compression less desirable, to the point that 
>> people did not complain much when browser vendors removed compression 
>> following the CRIME attacks. True, the rise of mobile brought back limited 
>> bandwidth, but is this really an issue?
>> 
> I don't think using bandwidth as a factor is a good idea.
> 
> 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 because South American countries are going places
> American and Europeans have already been with respect to
> infrastructure).

At some point the countries with the least developed infrastructure eventually 
go through some government-led project to improve infrastructure, and that 
makes them leapfrog most other countries just because all their infrastructure 
is suddenly new. It happened in South Korea 15 years ago, and it’s happening in 
many African countries now. I don’t think we should burden a security protocol 
with a problematic mode based on a perceived need that might evaporate in a 
couple of years. Deploying high bandwidth is even faster now that you can make 
the last mile wireless rather than running copper or fiber to individual homes.

> In the rural US, I understand low bandwidth is the norm. Those folks
> can't get companies like Verizon or Comcast to service them due to
> population density. Its just not profitable for the providers to
> update the infrastructure. Also see
> https://www.google.com/search?q=rural+us+high+speed+internet.

That supports my point.  To quote one of the top results from that search (the 
first one that was not an ad):

"53 percent of rural Americans have no access to high-speed Internet, 
which he defined as capable of downloading content at 25 megabits per second.”

15 years ago, having “no access to high-speed Internet” meant having just 
56Kbps dial-up modem. 10 years ago it meant not having access to 0.5 Mbps 
broadband. The bar is now significantly higher. And you don’t usually need 25 
Mbps for NNTP, although the last time I actually used NNTP was over a 56Kbps 
modem. 

Yoav
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Julien ÉLIE]

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

[...]

What we need for NNTP is a build without security, but with compression
option.


And it is probably the case for protocols other than NNTP.
The current discussion focuses on NNTP but I bet the same question can 
arise from other protocols.


--
Julien ÉLIE

« On a toujours tort d'essayer d'avoir raison devant des gens qui ont
  toutes les bonnes raisons de croire qu'ils n'ont pas tort. »
  (Raymond Devos)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Björn Tackmann]

> 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 increases attack surface
> and (2) people use compression, then wouldn't the best place to
> address it be in a protocol or security library rather than pushing it
> into a higher level in the stack where it likely won't be addressed?

No, because compression is not a good idea for the general use case of TLS. It 
might be a good idea for specific applications (where there may be specific 
reasons for which it will not violate security), but then one can (and should) 
resolve it specifically for those applications. Even within one application, 
there may be parts where the security suffers from compressing, and some where 
it does not. Only the application can make this decision.


Best,
Bjoern


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bill Frantz]

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 increases attack surface
and (2) people use compression, then wouldn't the best place to
address it be in a protocol or security library rather than pushing it
into a higher level in the stack where it likely won't be addressed?


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




I do have a lot of sympathy with those who have been using compression in
previous versions of TLS. Probably the best solution for them is to have a
TLS like library which only does compression. It could be largely API
compatible so switching between TLS and compression is a relatively easy
programming job. I'll let the TLS implementers say just how hard such a
library would be to produce.


OpenSSL currently has an configuration option to build without
compression methods (no-comp). I usually build OpenSSL without
compression, and OWASP recommends building without compression
(https://www.owasp.org/index.php/C-Based_Toolchain_Hardening).


What we need for NNTP is a build without security, but with 
compression option.


Cheers - Bill

---
Bill Frantz| Ham radio contesting is a| Periwinkle
(408)356-8506  | contact sport.   | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jeffrey Walton]

> 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 nowhere near that. 
> This makes compression less desirable, to the point that people did not 
> complain much when browser vendors removed compression following the CRIME 
> attacks. True, the rise of mobile brought back limited bandwidth, but is this 
> really an issue?
>
I don't think using bandwidth as a factor is a good idea.

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 because South American countries are going places
American and Europeans have already been with respect to
infrastructure).

In the rural US, I understand low bandwidth is the norm. Those folks
can't get companies like Verizon or Comcast to service them due to
population density. Its just not profitable for the providers to
update the infrastructure. Also see
https://www.google.com/search?q=rural+us+high+speed+internet.

Ironically, Steve Marquess of the OpenSSL Foundation is one of those
affected by provider's decision based on profitability.

Jeff

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

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 flaw, I want to 
>> move to TLS 1.3 without losing data compression."
>>
>> Is this accurate?
> I think the other counter-argument is that modifying NNTP to have a 
> compression feature is hard, whereas updating the TLS library is something 
> that implementations are likely to do.
>
> 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 nowhere near that. 
> This makes compression less desirable, to the point that people did not 
> complain much when browser vendors removed compression following the CRIME 
> attacks. True, the rise of mobile brought back limited bandwidth, but is this 
> really an issue?

Well, this just came across my browser:
http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new-compression.html

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Julien ÉLIE]

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 need to get rid of all of the insecure modes so all
configurations are secure (at least to start).


This is compatible with keeping compression as a mode that can be 
explicitly activated.


--
Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

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 secure as possible by default.


On Tue, Sep 22, 2015 at 12: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 flaw, I
> want to move to TLS 1.3 without losing data compression."
> >
> > Is this accurate?
>
> I think the other counter-argument is that modifying NNTP to have a
> compression feature is hard, whereas updating the TLS library is something
> that implementations are likely to do.
>
> 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
> nowhere near that. This makes compression less desirable, to the point that
> people did not complain much when browser vendors removed compression
> following the CRIME attacks. True, the rise of mobile brought back limited
> bandwidth, but is this really an issue?
>
> Yoav
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Simon Josefsson]

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 before (and after) the secret. With NNTP you
>> may escape the worst of this adversary, but you probably won’t find
>> any TLS expert willing to say that compressing the password is ok.
>
> OK, many thanks for the illustration!
>
> So in fact, to be safer, authentication commands should either be sent
> uncompressed or be more complex than they currently are (for instance
> with the insertion of random data with random length along with the
> authentication command).

I believe the general recommendation is to not send passwords in
cleartext at all, even in encrypted tunnels.  I'm sure you are aware of
it, but you may SASL in NNTP as described in RFC 4643.

/Simon


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Julien ÉLIE]

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 would predict that HTTP isn't vulnerable.


I don't understand that point for AUTHINFO.
NNTP only answers "281 Authentication succeeded" or "481 Authentication 
failed" here, whereas HTTP response bodies are far more complex and part 
of the request may be reflected in the response.


--
Julien ÉLIE

« Etna : lave dévalante. »

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Karthikeyan Bhargavan]

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 PASS test
281 Authentication succeeded

From a formal security viewpoint, the logic behind disabling compression in 
this exchange is as follows.
TLS does not hide the length of plaintext, so an 8-character password  is 
distinguishable from a 4-character one.
While this loss of confidentiality may arguably be expected and acceptable, 
compression makes it worse.

Consider the two lines:
AUTHINFO PASS 
AUTHINFO PASS 12345678

Both passwords have 8 characters, and so when no compression is used, a passive 
network adversary cannot distinguish between them.
However, if they are compressed with gzip, the first results in 7 fewer bytes 
than the second. 
So compression of this line already yields 3 bits of the password to a passive 
adversary.
No online attack needed so far.

Suppose, the client also uses this password with a different command (e.g. 
XSECRET).

XSECRET test 
XSECRET test 12345678

Now looking at the compressed lengths of this, the passive attacker can get 
another 3 bits. Considering that the average password entropy can be as low as 
20 bits [1], the attacker now has a significant headstart on any other attack 
she may wish to pursue. 

HTTP is a particularly bad case because the attacker can potentially inject 
arbitrary data before (and after) the secret. With NNTP you may escape the 
worst of this adversary, but you probably won’t find any TLS expert willing to 
say that compressing the password is ok.

Best,
Karthik

[1] 
http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf


> On 20 Sep 2015, at 14:09, Julien ÉLIE  wrote:
> 
> 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 would predict that HTTP isn't vulnerable.
> 
> I don't understand that point for AUTHINFO.
> NNTP only answers "281 Authentication succeeded" or "481 Authentication 
> failed" here, whereas HTTP response bodies are far more complex and part of 
> the request may be reflected in the response.
> 
> -- 
> Julien ÉLIE
> 
> « Etna : lave dévalante. »
> 
> ___
> 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

[Julien ÉLIE]

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 you
may escape the worst of this adversary, but you probably won’t find
any TLS expert willing to say that compressing the password is ok.


OK, many thanks for the illustration!

So in fact, to be safer, authentication commands should either be sent 
uncompressed or be more complex than they currently are (for instance 
with the insertion of random data with random length along with the 
authentication command).


If TLS 1.3 is used, so without compression facility, adding a new 
COMPRESS command to NNTP will not help if how authentication is done is 
not strenghtened at the same time, won't it?

Or AUTHINFO is not a valid command after the use of COMPRESS.

--
Julien ÉLIE

« Etna : lave dévalante. »

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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/mailman/listinfo/tls

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

[Watson Ladd]

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 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.
> For instance:

This analysis would predict that HTTP isn't vulnerable. Furthermore,
the whole point is that TLS is supposed to provide certain services to
upper levels, and not require this kind of detailed analysis in
security designs.

>
> AUTHINFO USER test
> 381 Enter password
> AUTHINFO PASS test
> 281 Authentication succeeded
>
> or in the case of an authentication failure:
>
> AUTHINFO USER test
> 381 Enter password
> AUTHINFO PASS badpassword
> 481 Authentication failed
>
>
>
> How compression would make NNTP weaker?
> (Brute-force attack is still necessary, even with compression enabled.)
>
> --
> Julien ÉLIE
>
> « Etna : lave dévalante. »
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

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

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

[Julien ÉLIE]

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) where confidentality is desirable and so
compression needs to be specified very carefully if at all.


OK, understood.



Even in NNTP, you don't want compression if you're using
AUTHINFO---and how do you know AUTHINFO will or won't be used at the
time of STARTTLS?


Note that AUTHINFO can also use any available SASL mechanisms instead of 
sending plain user/pass.  (Depending on the SASL mechanism, a security 
layer can be negotiated during the SASL exchange.)  Unfortunately, that 
facility is not wide-spread in news clients and servers.


To respond to your question, STARTTLS is not available after a 
successful authentication.  Therefore, it cannot be used after STARTTLS. 
 RFC 4642 states:


   A server supporting the STARTTLS command as defined in this document
   will advertise the "STARTTLS" capability label in response to the
   CAPABILITIES command ([NNTP] Section 5.2).  However, this capability
   MUST NOT be advertised once a TLS layer is active (see Section 2.2.2)
   or after successful authentication [NNTP-AUTH].

However, though that practice is discouraged, most of news clients still 
connect to port 563 (dedicated to NNTPS) and negotiate a TLS security 
layer upon connection.  They do not use STARTTLS in that case; and 
clients can authenticate with AUTHINFO, with an active TLS layer.


--
Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

 
> 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.  That facility will then be lost.

Yes.

It is widely recognized that in many cases, TLS-level compression is flawed 
(for example NNTP authinfo?).  TLS 1.3 does not have it.  So NNTP that needs 
compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things can 
change.

/r$

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dave Garrett]

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 to use compression.  That facility will then be lost.
> 
> Yes.
> 
> It is widely recognized that in many cases, TLS-level compression is flawed 
> (for example NNTP authinfo?).  TLS 1.3 does not have it.  So NNTP that needs 
> compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things 
> can change.

Contrary to its name, TLS is not a transport protocol. It's a security 
protocol, and compression is not a security feature. (though, when combined 
with padding, I could see how it could be useful) It didn't belong in the spec 
like it was, even if it worked safely. It might be doable in a TLS extension, 
but I don't think this is a great idea. Application protocols can handle 
compression better and more safely, as they can actually know what they're 
doing and how to properly compress it.

Even if TLS compression could be fixed, the old insecure junk doesn't magically 
go away. It needs to be treated as ruined forever, just to be safe, as far as 
I'm concerned. If you need compression, I wouldn't recommend relying on it here.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Julien ÉLIE]

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 layer without compression has 
been negotiated?
It cannot guess it; and it won't try all uncompression methods to see 
which one has been used.


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 its 
implementation afterwards.


I bet other protocols would also need similar new specifications to 
explain how compression can be enabled.


--
Julien ÉLIE

« Etna : lave dévalante. »

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls