Re: [openpgp] Deprecating compression support

Bart Butler <bartbutler@protonmail.com> Wed, 20 March 2019 18:47 UTC

Return-Path: <bartbutler@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EECD1200B3 for <openpgp@ietfa.amsl.com>; Wed, 20 Mar 2019 11:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu6BF7zXoiqh for <openpgp@ietfa.amsl.com>; Wed, 20 Mar 2019 11:47:31 -0700 (PDT)
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890E613115F for <openpgp@ietf.org>; Wed, 20 Mar 2019 11:47:31 -0700 (PDT)
Date: Wed, 20 Mar 2019 18:47:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553107649; bh=2o0OBgBY3B8SUhnOpHVAomWoWA4P/ruI/gEQW46BYhs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ktwV+W7CRu8oXNGKbx0c9Ugyjx2mCW+ET9h/cbikWOYIbIQqaWF89CQ+C/kbwfjiv Bn4yDcV3CCH8BWydnNGm1tgQJx5KnU6ODA6GI4NPrl17aO0BzKU2Em4GGCpVdgI1A4 wUiyRfCthMlHXyNnNEQEix1NYLptUH0cfQbYnNv8=
To: Andre Heinecke <aheinecke@gnupg.org>
From: Bart Butler <bartbutler@protonmail.com>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>, Justus Winter <justuswinter@gmail.com>
Reply-To: Bart Butler <bartbutler@protonmail.com>
Message-ID: <xEPyX3yGpisVL1Tl_L1w_HI_zAAbfs3j9Itg0iZ_GxbxtkEoB_WJWvGjbHcdfb2BJx0rnIujUqVrFbIZNhUXWAGAm79B0fwHqoOiGxSk5tk=@protonmail.com>
In-Reply-To: <2181951.mQFCbn3PMz@esus>
References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus>
Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------0adde572306aa4a1b04d254010698af2"; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/7jGv91--Xw2AiBzSuG-NrazoBDk>
Subject: Re: [openpgp] Deprecating compression support
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 18:47:35 -0000

I tend to agree with Andre. Compression still has its place. For example, we are an email provider and receive millions of email per day, most of which are text and thus highly compressible, and due to the volume it's actually an appreciable amount of storage space (read: money) that we save via compression. There's also no BREACH/CRIME risk in this particular use case and in many other use cases for PGP.

>From the library perspective decompression support is certainly here to stay basically forever for legacy messages at the very least, so I don't see a lot of benefit to implementation developers from dropping support either. If you have a streaming interface, you'll still need to support streaming decompression.

One thing we could add to the compression section would be a SHOULD for ZLIB as opposed to the legacy ZIP and bzip2, which is slow and doesn't have much of a reason to exist in my opinion. There's no real guidance right now to which is preferred. I'd also be happy deprecating creation of new messages with ZIP and bzip2 if we wanted to go there, though maybe someone has a use case that I'm not aware of.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 20, 2019 7:53 AM, Andre Heinecke <aheinecke@gnupg.org> wrote:

> Hi,
> 

> Vincent said that my mail was too rambling. I agree. Here is the short
> Version:
> 

> -   Compression is good and necessary.
> -   Standardized compression is good.
> -   I don't want to use unstandardized compression only because you do not want
>     to implement compression in sequoia.
>     

> -   There is no reason the change the standard. Compression has been around for
>     ages. It is standard and working well.
>     

> 

> Here is where annoyed rambling about unproductive suggestions starts:
> 

> > -   Compression makes it impossible to reason about the size of a
> >     decrypted message, requiring the use of a streaming interface even
> >     

> 

> > for seemingly small messages, e.g. emails. Experience has shown
> > that downstream users struggle with the correct use of streaming
> 

> > interfaces.
> 

> Whose expericence? Not mine. It's OpenPGP and S/MIME. You have to handle this
> even if you don't like it. Compression does not change this.
> 

> > -   Compression allows the construction of quines.
> 

> Yeah that sucks. But a downstream application would still be affected. e.g. a
> MUA or Kleopatra if you move compresssion out of the standard.
> 

> > -   Compression interacts badly with encryption, see e.g. CRIME,
> >     BREACH, and hiding of EFAIL-style CFB gadgets [0].
> >     

> 

> rolleyes Was OpenPGP affected? Nope.
> 

> > -   The downstream application is in a better position to decide whether
> >     and how to compress data that is then encrypted using OpenPGP.
> >     

> 

> Nope. Because the downstream application does not know anything about the
> sending application because it is not standardized in you proposal.
> 

> > -   Compression make the standard more complex, and enlarges the
> 

> > trusted computing base of implementations.
> 

> Nope. Removing it makes handling it more complex because we are working with a
> well established standard. So you still need to handle old messages so you
> still need to handle compression. But Oh! Now you also have to handle non-
> standard compression. Fun! Complexity -> Increase!
> 

> Regards,
> Andre
> 

> -----------------
> 

> GnuPG.com - a brand of g10 Code, the GnuPG experts.
> 

> g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
> GF Werner Koch, USt-Id DE215605608, www.g10code.com.
> 

> GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf. VR 11482 Düsseldorf
> Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org
> Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799_______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp