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

[Julien ÉLIE <[e-mail]>]

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


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.

I understand that a few protocols (like HTTPS) have vulnerabilities when 
compression is used.  Nonetheless, is it a sufficient reason to no 
longer support compression in TLS 1.3?
Wouldn't it be better to disable compression in implementation of 
vulnerable protocols?  (For instance Firefox, Apache...)

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.

-- 
Julien ÉLIE

« La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »