Pros and cons of PGP/MIME for outgoing e-mail?

[Bjarni Runar Einarsson]

Werner Koch <wk at gnupg.org> wrote:
> On Mon, 24 Nov 2014 10:25, bre at pagekite.net said:
> 
> > is that they do generate valid MIME - after swearing at Python for
> > months, it dawned on me that it's probably the PGP/MIME standard that is
> > just being too picky.
> 
> Please explain that.  RFC-3156 was released in 2001 to even relax some
> requirements of RFC-2015 (1996).  Now compare that to the various
> problems with PGP-2 clear signed messages passing different gateways and
> systems - all kind of fun happened depending on the versions of
> PGP/GPG/FOO you used.  RFC-3156 has a simple set of of requirements to
> help the trailing Tab/Space/CR problems.

Hmm. I think some of the headaches I was having were caused by the
Python MIME libraries giving me inconsistent serializations of the
message parts, and not preserving the raw payload in others. I had to
bypass the parser entirely in order to verify signatures.  Maybe I was
using the API wrong. I dunno. But that's exactly the point, if you don't
implement your MIME parsing exactly right, PGP/MIME just fails horribly.

Similarly, when generating messages I had to fork the Python lib's
generator and disable various "helpful" hacks that were randomly
mutating the behavior of the generator if it detected it was generating
an encrypted message!

> > This is part of what I meant by tightly coupled in a previous e-mail -
> > unless MIME libraries and interfaces are explicitly written with
> > PGP/MIME in mind, and carefully tested, they easily end up being
> 
> All the problems I have seen with MIME were due to incomplete MIME
> implementations which barely worked ... and one which did ugly things to
> mails internally passing from one animal to the other.  And no, the
> latter was not Outlook (which not claimed to be an RFC-822 aware mail
> client)
> 
> > incompatible. MIME is a forgiving standard, PGP/MIME is emphatically
> > not. This causes headaches for people trying to implement PGP/MIME and
> 
> It is related to encrypted - it can't be for signatures.  The whole
> point of signatures is that you want to verify that the mail did not
> change.

You want to verify that the message composed by the user did not change
- the technicalities of the container it is placed in could well have been considered out of scope. Requiring that white space placement and irrelevant things like boundary strings stayed unchanged is unnecessary and in practice counterproductive because it tightly couples parser/generator implementations with the security evaluation, leading to implementation difficulties and false positives. This is not helpful. False positives train users that security failures don't mean anything, and PGP/MIME seems designed to maximize such things.

It would be far, far more useful to have a signature for each part so
instead of a binary pass/fail, you get a more granular result saying
"Message body was fine", "Attachment 2-5 are fine", and "Something (probably a mailing list) injected some foreign content".

> BTW, the standard practice in the industry seems to be encrypt the
> document and attach it.  That is an easy to learn workflow and works
> identical to the way many companies send letter (e.g. PDF attached).

That is basically the kind of workflow my proposal emulates, is
compatible with and attempts to improve upon.

> Anyway, the question is what you define as meta data: Only the
> addresses?  The attention line/the subject?  Good MUAs inform the user
> that the subject will be send in the clear and that can actually be good
> thing for fast scanning of mails.

My proposal was to move any and all interesting headers into an
encrypted (or merely signed) attachment I am calling a "manifest". You
can think of it as an extended signature, that both protects the headers
and provides a signature for each individual part of  the message. That
way it can validate contents and structure, and also transmit headers we
would like to omit from the public RFC2822 header - without assuming or
imposing anything about the low level technical structure of the MIME
itself.

This is a very low impact proposal which doesn't break compatibility
with anything - you could even use it with PGP/MIME just to protect the
message headers. But it has the potential to provide similar security
benefits as PGP/MIME, without the implementation complexity and tight
coupling. I even propose the format be human readable so people can do
manual verification if they like. :-)

> > 2) Is there any interest in trying to improve the standards?
> 
> Counter question: Is there any interest in fixing the remaining non MIME
> capable MUAs?

Hah, you dodged the question. ;-)  I'd love it if all the software got
fixed. But even though improving standards is hard, I'm going to wager
that this task is even harder.

Cheers!
 - Bjarni

-- 
I make stuff: www.mailpile.is, www.pagekite.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20141124/533ab517/attachment.sig>