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

Bill Frantz <> Thu, 24 September 2015 01:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D41D21B361B for <>; Wed, 23 Sep 2015 18:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sLaArVIrXGER for <>; Wed, 23 Sep 2015 18:59:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BEFFB1B361A for <>; Wed, 23 Sep 2015 18:59:17 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4.67) (envelope-from <>) id 1ZevoV-0007Nk-Jr; Wed, 23 Sep 2015 21:59:11 -0400
Date: Wed, 23 Sep 2015 18:59:06 -0700
From: Bill Frantz <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r422Ps-1075i-B098BF70B2E7444B9FA0756D7BFB90F4@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec790f646c9d612136521ebfbe9d6bf5bff6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Sep 2015 01:59:20 -0000

On 9/23/15 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?

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

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 |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032