Re: [openpgp] Deprecating compression support

[Bart Butler <[e-mail]>]

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 <[e-mail]> 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: [e-mail]
> Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: [phone]_______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp