Vincent Breitmoser <look@my.amazin.horse> writes:
Andrey Jivsov <crypto(_at_)brainhub(_dot_)org> wrote:
I agree with deprecation at a reasonable pace. SHOULD looks right.
I'm unsure why both Jon and you think we need a slower "reasonable pace", when
we have not only one but two very sharp points to make this cut as clean as
can
be? Both AEAD and the v5 key format already break compatibility. Why pull
something over the edge that we want to phase out anyways?
Agreed. I prepared a patch:
Author: Justus Winter <justus(_at_)sequoia-pgp(_dot_)org>
Date: Tue Mar 19 16:11:03 2019 +0100
Deprecate compression support.
Forbid compression if encrypting a message to version 5 keys, or if
AEAD is used. Discourage compression otherwise. Drop the dubious
paragraph about security benefits of compression.
Motivations:
- 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.
- Compression allows the construction of quines.
- Compression interacts badly with encryption, see e.g. CRIME,
BREACH, and hiding of EFAIL-style CFB gadgets [0].
- The downstream application is in a better position to decide whether
and how to compress data that is then encrypted using OpenPGP.
- Compression make the standard more complex, and enlarges the
trusted computing base of implementations.
0: Section 5.3 of https://efail.de/efail-attack-paper.pdf
diff --git a/middle.mkd b/middle.mkd
index 44d1246..4f88eb2 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -129,21 +129,21 @@ and a public-key signature algorithm. The sequence is as
follows:
## Compression
-OpenPGP implementations SHOULD compress the message after applying the
-signature but before encryption.
+OpenPGP implementations MUST NOT compress the message if the list of
+recipients includes a version 5 key, or the message is encrypted using
+AEAD.
+
+Otherwise, OpenPGP implementations SHOULD NOT compress the message
+after applying the signature but before encryption.
+
+For backwards compatibility, OpenPGP implementations MAY handle
+compressed data packets.
If an implementation does not implement compression, its authors
should be aware that most OpenPGP messages in the world are
compressed. Thus, it may even be wise for a space-constrained
implementation to implement decompression, but not compression.
-Furthermore, compression has the added side effect that some types of
-attacks can be thwarted by the fact that slightly altered, compressed
-data rarely uncompresses without severe errors. This is hardly
-rigorous, but it is operationally useful. These attacks can be
-rigorously prevented by implementing and using Modification Detection
-Codes as described in sections following.
-
## Conversion to Radix-64
OpenPGP's underlying native representation for encrypted messages,
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp