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