Subject: [openpgp] PGP/MIME message mangling

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 22 May 2019 03:40:10 -0400

Hi people interested in OpenPGP and PGP/MIME--

I think anyone who has worked with PGP/MIME messages has seen some MTAs
break message structure or formatting in ways that make it difficult or
impossible to perform the correct cryptographic operations on the
message according to the specs.

The fact that the mangling MTA may not be operated by the party whose
message it is mangling makes it rather difficult to report the problem
and get it fixed.  That difficulty is exacerbated by not having a clear
reference for the problem.

Additionally, when some of those manglings become widespread or common,
some implementers craft workarounds based on examples of the
misbehavior.  But often these workarounds are ad-hoc or private -- they
aren't subject to review from the community, and they are tucked away in
code that isn't particularly visible, leading many implementers to
stumble upon similar problems independently and try to work around them
on their own.

I've just published a new draft that aims to collect examples of these
manglings, and recommendations about sensible ways to handle them safely
if you encounter them:

    https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling-00

Only one particular mangling is fully fleshed out in the -00 release
(I've named it "Mixed up" encryption), but a few more are pointed at in
TODOs.

If you have any examples of mangled messages sitting around -- in your
implementation's test suite, in your pile of bugs-to-be-reported, please
think of this draft as a place to collect them, as well as a place to
document how to most effectively work around these failures as they are
encountered by a friendly MUA.

My preferred goal, of course, is to get the MTAs to stop mangling
messages.  If this draft can be used as a reference for that kind of bug
report ("Your MTA appears to be mangling messages according to section
X.Y of this draft"), great!  But even if we succeed in fixing existing
implementations, mangled messages may linger indefinitely in archives,
so having a reference for how to deal with them safely will hopefully be
useful.

I welcome comments and feedback here on the list, and pull requests or
open issues at
https://gitlab.com/dkg/draft-openpgp-pgpmime-message-mangling

I hope this is useful work!

  --dkg

---

From: Albrecht Dreß <[email-masked]>
Date: Thu, 23 May 2019 19:36:34 +0200

Am 22.05.19 09:40 schrieb(en) Daniel Kahn Gillmor:
> I've just published a new draft that aims to collect examples of these manglings, and recommendations about sensible ways to handle them safely if you encounter them:

This will be very helpful IMHO!

> If you have any examples of mangled messages sitting around -- in your implementation's test suite, in your pile of bugs-to-be-reported, please think of this draft as a place to collect them, as well as a place to document how to most effectively work around these failures as they are encountered by a friendly MUA.

For multipart/signed, the signature may be broken by MTA (and POP3) transactions if any line in the data stream starts with a period (“.”, ASCII 0x2e) character.  In this case, RFC 5321, Sect. 4.5.2 and RFC 1939, Sect. 3, require that the period is doubled for the transmission, which the receiving party shall remove.  If it fails to do so, obviously the signature is broken.  The workaround is to just remove the extra period.

Actually, a message I sent to this list (<https://mailarchive.ietf.org/arch/msg/openpgp/SKclvRGw9kan13GSsP66NlHHKEc>) reached my mailbox with /exactly/ this error – in the line containing “[…]RFC 3156, sect. 5 states that[…]” the period has been doubled.  I verified with some test messages that neither my provider's MTA nor my POP client produces the issue…

Best,
Albrecht.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 23 May 2019 23:30:56 -0400

On Thu 2019-05-23 19:36:34 +0200, Albrecht Dreß wrote:
> For multipart/signed, the signature may be broken by MTA (and POP3)
> transactions if any line in the data stream starts with a period (“.”,
> ASCII 0x2e) character.  In this case, RFC 5321, Sect. 4.5.2 and RFC
> 1939, Sect. 3, require that the period is doubled for the
> transmission, which the receiving party shall remove.  If it fails to
> do so, obviously the signature is broken.  The workaround is to just
> remove the extra period.
>
> Actually, a message I sent to this list
> (<https://mailarchive.ietf.org/arch/msg/openpgp/SKclvRGw9kan13GSsP66NlHHKEc>)
> reached my mailbox with /exactly/ this error – in the line containing
> “[…]RFC 3156, sect. 5 states that[…]” the period has been doubled.  I
> verified with some test messages that neither my provider's MTA nor my
> POP client produces the issue…

Thanks, Albrecht!  This is exactly the kind of stuff I'm looking for.

I've just added a "Doubled Dots" subsection to the draft at
https://gitlab.com/dkg/draft-openpgp-pgpmime-message-mangling that is a
copy of the first paragraph above as a placeholder, and a sample
clearsigned message with and without the mangling applied.

If you are up for proposing more detailed text, i'd be happy to take
recommendations, either as git merge requests or here on the mailing
list.

I think the remediation you proposed needs to be fleshed out a little
bit for robustness, though -- for example, you don't want to just remove
double-dots on every message that contains them.  You only want to try
removing doubled dots if you find them in the message *and* the message
signature does not validate.  Then you can try validating the message
with the doubled dots removed, and if so, use the repaired message.

Thinking with an implementer's hat on, and the worst-case scenario
paranoia that goes with it, i wonder how many iterations one should try
to apply such a repair operation before giving up and accepting that the
message doesn't have a good signature?

        --dkg