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
