Hi Justus--
On Tue 2019-09-24 19:09:04 +0200, Justus Winter wrote:
To reduce the amount of information leaked via the message length (see
e.g. [0]), encrypted OpenPGP messages should include decoy traffic.
0: https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys
Thanks for this thoughtful analysis of different padding mechanisms for
OpenPGP encrypted packets.
I note that deciding on a padding mechanism ("how do i pad?") at the
OpenPGP layer is not the same as deciding on a padding policy ("how much
do i pad in a given circumstance?")
We've been having increased dicsussion around the IETF about traffic
analysis, and from what i've seen the general consensus (e.g. in TLS and
DPRIVE) has been:
* Size-based traffic analysis is a potentially serious threat to some
applications that rely on encrypted traffic. Responsible protocol
designers need to consider countermeasures.
* The ideal place to apply padding is at the application layer -- or
even higher in the stack -- because the upper layers are closest to
understanding the typical size characteristics of messages that they
emit and receive, and the risks of size-based traffic analysis at
those layers.
* Some application layer traffic is fairly ossified (the cleartext
structures cannot be modified without significant cost), and has no
native mechanism to safely pad. And the encryption protocols
themselves sometimes leak sizing data in unfortunate ways. So a
responsible encryption mechanism that might be used to encapsulate
different application-layer traffic, or have its own size-based
leakage should include a well-understood padding mechanism. That
way, an ossified application layer can exercise the encryption
layer's padding scheme to defend against traffic analysis without
touching the application data.
* Designing a padding policy is likely better done independently from
designing a padding mechanism. As long as the padding mechanism is
available, then the application layers can declare their preferred
padding schemes.
* The preferred padding policy for a given application layer may change
over time as the use of the protocol changes. Having it designated
separately allows adjustment of the policy without having to fiddle
with the mechanism.
Given the above, i agree with you that the OpenPGP specification should
explicitly warn implementers and higher-layer users of OpenPGP to
consider the risks of traffic analysis and encourage countermeasures
that obscure the size of the cleartext.
However, i don't think that the OpenPGP specification should declare a
preferred padding *policy* -- that's best discussed in the context of an
application that uses OpenPGP, and might well be different for different
applications.
I'm of two minds about declaring a standard padding *mechanism* for
OpenPGP in the main specification itself. If there was one obvious
mechanism for padding that was already in wide use, i'd say we should
include it in 4880bis. But as there appear to be many possible
mechanisms, and there may be subtle tradeoffs between different
mechanisms, and 4880bis is already long overdue, i'd recommend
documenting a preferred padding mechanism (without trying to impose a
preferred padding policy) in a separate draft, including a bit more
justification about why this scheme is preferable to the other
possibilities.
As for your current proposal (using a compressed packet as padding), i'm
concerned about the interaction between features -- does it mean that if
the recipient has marked their OpenPGP certificate as unable/unwilling
to use decompression, that they cannot receive padded messages? Is
there a way to mark padding explicitly as padding so that a clever
implementation doesn't need to exercise any decompression code just to
throw away the padding packet?
Would you be interested in writing a more narrowly-scoped merge request
for 4880bis that directs application layers that use OpenPGP to consider
the risks of size-based traffic analysis, and apply padding-based
countermeasures where possible?
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp