Re: [openpgp] Padding packets

[Daniel Kahn Gillmor <[e-mail]>]

On Tue 2022-06-21 10:02:14 +0000, Daniel Huigens wrote:
> To be perfectly honest, I think the protection against compression is
> somewhat dubious, in general. If I pad a message and *then* compress,
> there may still be length differences due to differences in the
> message, so the protection the padding is meant to offer is reduced,
> or even removed.

You're right that the metadata fields in OpenPGP packets are themselves
fairly low-entropy, so the protection a padding packet can provide
against compression isn't going to be bulletproof.

But requiring a fixed high-entropy string when under compression adds an
additional risk: it makes it possible for an adversary that is capable
of injecting data somewhere in the non-padding sequence to test whether
a padding packet is present, by injecting some part of the mandated byte
sequence (this is similar to how the CRIME attack against HTTP works).
So the fixed-string approach weakens further the defense against
accidental content leakage based on compression.

> So - personally, I would also not be entirely opposed to setting the
> padding to all zeros, and saying that if length protection is desired,
> compression must not be used. In an encrypted message, the OpenPGP
> implementation obviously has control over this itself; and in the case
> of WKD the server also has control over this.

IIRC, the padding packet was initially proposed as containing all-zeros,
as a way to avoid adding yet another side channel; the DT changed it to
high-entropy data specifically because of concerns about compression.

As we make this decision collectively, we should also remember that
compression can take place outside the OpenPGP layer (e.g. if the
OpenPGP packet stream is being sent over a web server, it might do
on-the-fly gzip compression).

If we recommend that the packet contain all-zeros as proof of
no-covert-channel, i *still* don't think it's advisable to require
implementations to reject the entire packet sequence if any non-zero
data is found in a padding packet.  At most i'd say that some
implementations may want to warn the user that there may be hidden
data (but see [*] below).

The two places that padding is currently recommended for an OpenPGP
packet sequence that want to obscure message length are:

 a) encrypted messages (the last packet in the packet stream inside an
    unwrapped SEIPDv2 packet)

 b) at the end of an OpenPGP certificate (which is presumably sent over
    encrypted channels, like WKD)

In either of these contexts, any message generator that wants to embed
arbitrary data can do so.  At least the following channels are possible:

 (A) Inside the SEIPDv2-wrapped packet stream, the message generator can
     prefix the desired packet stream with a Signature packet, marked
     with a pubkey algorithm in the experimental range.  The content of
     this packet can contain anything.  It should be ignored by the
     recipient, as any signature from an unknown algorithm will be
     ignored by any consumer.

 (B) In an OpenPGP certificate, the message generator could stuff
     arbitrary non-critical subpackets marked with experimental
     subpacket types (or, notations, with a novel notation name) into
     the unhashed region of any and all certifications in the
     certificate, including the self-sigs.  Non-critical subpackets of
     unknown type, in the unhashed region, will be ignored by any
     consumer.

 (A.2) in the event that the SEIPDv2-wrapped packet stream already
       contains a signature packet, the generator can also stuff
       arbitrary data into the signature's unhashed subpacket area as
       well, without adding an explicit additional packet.

(see also the rejected
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/112/diffs for
even more possible existing mechanisms)

So the padding packet doesn't open a *new* covert channel, regardless of
how it is specified.

[*] Any implementation that thinks it would be important to warn the
    user about a high-entropy covert channel in the padding packet's
    contents (let alone to reject a high-entropy covert channel in
    padding) should *also* already be warning the user about potential
    covert channels in the above types of data.  I'm unaware of any
    existing implementation that warns the user, let alone rejects a
    packet stream on these grounds.

So, why have a padding packet at all if these other mechanisms are
available?  Simplicity, clarity, and robustness.

By formalizing a place to do padding, implementers don't have to invent
the options described above, or come up with some other crazy scheme.
It's also easier to do than subpacket injection (appending a packet
rather inserting, which would requires packet header manipulation).  And
by allowing padding within the OpenPGP layer, the message can be padded
even if it is being transported over a mechanism that doesn't have
another way to do padding.  Making its content unpredictable and
high-entropy is a way to reduce (but not completely eliminate) the risk
of some external compression layer accidentally defeating the purpose.

Having an explicit padding packet will hopefully encourage implementers
and deployers to consider metadata leakage, which is increasingly
important as we move to a majority-encrypted network.

          --dkg