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]

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

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

-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

[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

[Daniel Kahn Gillmor]

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 don't do renegotiation or
require secure renegotiation, and you don't use TLS-Unique, and you're
ok with fully-cleartext handshakes, and (maybe something(s) else i'm
forgetting) ...

I don't think we should be claiming that TLS 1.2 is equivalent to TLS
1.3 without many more caveats.   :)

  --dkg

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

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

[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

[Yoav Nir]

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

And client certificate authentication in HTTP/2

(This assumes that HTTP/2 is required)

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