Re: [openpgp] Padding packets

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

On Fri 2022-07-15 11:45:47 +0100, Stephen Farrell wrote:
> If I were to suggest that we've converged onto merge
> request 204 ([2], use zeros for padding, recommend not
> compressing them) would I be wrong? Please correct me
> if so before Tuesday 19th if you can.

Thanks for this summary, Stephen!

With no hats on, I still prefer the status quo: no changes to the draft
text, encouraging but not requiring the use of high-entropy data in the
padding packet.

But I would be willing to accept merging something similar to (but
looser than) 204.  For example, encouraging the use of all-zeros and
recommending avoiding compression.

And if folks are ok with more complexity, I'd also be OK with something
similar to (but looser than) 203: encouraging the use of a pseudorandom
function with a reasonably high-entropy seed from a
variable-but-derivable value, that a wary recipient could confirm, and
warn about if it doesn't match (meaning there's a likely covert
channel).  but oof, that's a mouthful just to produce a warning that i
think is ultimately unactionable.

However, in its current state, i don't think 204 is OK.  it contains two
unenforcable MUSTs:

 1) Its contents MUST be all zero octets
 2) Padding MUST NOT be used in combination with compression at a higher level

While the generating application can obey point 1, it won't be a true
MUST (that is, causing a protocol interop failure if it isn't followed)
unless some *recipient* rejects any padding packet that is found to not
contain all-zeros.  That introduces unnecessary brittleness and i don't
think it's a good idea for the ecosystem.  why introduce this interop
failure?

For point 2, it (a) isn't enforcable by the generating application (in
many cases, you don't know whether the OpenPGP packet sequence you
produce will be transmitted over or stored on a compressed medium) and
(b) if it is enforced by the receiving application, will cause another
form of brittleness.  ("The OpenPGP certificate in this PKZIP file was
invalid because it contained a padding packet with non-zero content;
extract it to a normal decompressed file and then it will be acceptable"
seems like a not-useful workflow).

Even if we accept that these are sensible costs for the ecosystem to
bear, we haven't eliminated covert channels in OpenPGP more generally.
Someone could squat on a non-critical packet type, or inject
experimental subpackets in the non-hashed area, etc, and the covert
channel still exists.  *And* padding packets will be completely
ineffective under compression.

The simplest approach with what i see as the fewest downsides is to
recommend but don't enforce high entropy material in the padding packet.

        --dkg