On Mon 2015-06-08 10:32:18 -0400, intrigeri wrote:
> Anyway: the root cause of the problem is PGP/inline, and it's a real
> one (as explained in the thread that lead to this bug being filed
> IIRC, the sending MUA has no way to express what's the encoding of the
> cleartext, because it only sees the ciphertext that's encoded in
> US-ASCII). In some cases, and even possibly in the majority of cases,
> it works because the receiving MUA's assumptions are correct, but it
> cannot possibly *always* work because there's no robust way to
> correctly guess the encoding of a bytestring in all cases.
>
> I'm wrong, I'm sure dkg will happily correct me :)
Far from it, i was writing up this exact explanation when your message
came in. Thanks for writing it :)
Furthermore: It's not just about whether your peer's MUA is likely to
guess right, and whether a message is *likely* to be interpreted
correctly. You also have to evaluate the problem in an adversarial
context.
If this crucial piece of context (character encoding) is not
cryptographically protected, it can be manipulated by an attacker. If
the bytestream gets reinterpreted based on the attacker's modifications,
what kinds of errors can result?
About 30 minutes of fiddling around with malicious character encodings
got me to the "message tampering through header substitution" example
here:
https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/
It's not a world-shattering break, but it's clear that the context does
need to be protected in order for messages to be safely transmitted.
Inline PGP has no way to do that.
--dkg
