Re: [openpgp] Deprecating compression support

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(_at_)gnupg(_dot_)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(_at_)gnupg(_dot_)org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: 
+49-2104-4938799_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp