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

[Bernhard Reiter]

Hi Bjarni,

On Monday 24 November 2014 at 10:25:43, Bjarni Runar Einarsson wrote:
> Bernhard Reiter <bernhard at intevation.de> wrote:
> And thank you for the friendly reply. :-)

you are welcome! I know that some people sound a little but grumpy, but this 
mostly is the case, because they feel like they are reiterating well known 
arguments. This is partly true. Still I believe that we all feel some pressure
to make the situation better for users. So we may need to rethink the 
solutions radically again, to see if we come to the same answer.

> > I am on the PGP/MIME side of things, I recommend it as default for
> > sending out  emails. See also http://wiki.gnupg.org/SignatureHandling .
> >
> > a) for encrypted emails, there is no drawback. Every email client just
> > have to be able to deal with message/rfc822 mime-parts anyway.
>
> I actually disagree, the drawbacks are significant if you broaden the
> scope to include users of mail clients that do not have native support -
> which once you step out of the Free Software bubble, is most mail
> clients.

You are saying that "most mail" clients cannot handle PGP/MIME encrypted 
email. And you say that is especially true for web based email clients.
My argument starts at: almost all MUAs (mail user clients) can deal with MIME.
So they must have a working MIME parser.
For them to implement PGP/MIME for decryption is very easy:
Just decrypt the contents and put it through the parser they already have.
If someone aims for implementing this, it can be done easily.

> As discussed in my post, if you have a PGP key but are unable to use a
> PGP/MIME aware mail client for whatever reason (work supplied laptop, no
> Internet outside of Internet cafés etc.), then you will not easily be
> able to receive and decrypt PGP/MIME attachments, 

In this case of course they might also lack the standard tools to unzip
the archive in your first ad-hoc strategy. So it will be better to fall back
on an attachment (that includes an archive file) that people can decrypt.
Oh, what about the idea to just ship a MIME parser with GnuPG. >;)

If more people implement the good standard PGP/MIME, 
more clients will implement it as well.

So I see that sending PGP/MIME as default is good,
with an option that the user can fall back to a zipped and encrypted 
(gpg-zip/gpg-tar compatible format) attachment,  

> It is tempting to blame the Python libraries, but the fact
> 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.

The email standard library assumed that whitespace and header lines are 
insignificant (last time I've looked, I think I even filed an issue with 
mailman and with python, but it was a long while ago). So they completely 
disassemble them to put the together again when they are needed. In this 
process they strip whitespaces, headerlines and reformat linebreaks.
So there is a designed loss of information in the library. 
To me that is a design issue of the library. And I believe most other MIME 
libraries will not share it.

From the security point of view I think it is good that PGP/MIME enforces
that mime(sub)parts will not be modified, because if you allow changes there, 
which are to be assumed identical, you may introduce an attack surface 
because some clients may display the contents slight differently. A clever 
attacker may exploit this to play tricks on the user.

> 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
> incompatible. 

There is one criteria added to the design of MIME libraries:
If I save a mime object -- let us say an message/rfc822 -- I can get it out 
the same way I have put it in. I'd say that this would be good design anyway.
Again, the problem is only really there for signatures verification
or email forwarding or so.

For encryption, you are writing your own mime-parts so it is easy to not 
create strange headers or double whitespaces in them. For decryption you just 
decrypt the blob and then have a regular MIME structure.

> MIME is a forgiving standard, PGP/MIME is emphatically 
> not. This causes headaches for people trying to implement PGP/MIME and
> any source of friction like this reduces tool support and uptake.

There are some rules about whitespace to not have it getting in the way,
but in general conceptually I see no other way, if you want to make sure that
an email has not been tampered with.

> All the other issues aside, I don't think anyone will
> seriously argue that an e-mail encryption standard which transmits the
> subject line in the clear is a "good standard".

If you want some indication about what the communication is about before 
opening it, the indication has to be on the "envelope" and thus cannot be 
encrypted. Once opened, there can be a different contents. I can think of 
coming up with something where there is a second message/rfc822 within 
the message and the subject: line in there should be displayed instead of the 
envelope subject by email clients that have already done the complete 
decryption (though then you have the interface problem where to display the 
envelope subject). In total I would say that having an envelope subject is 
good anyway and that most email clients would continue to display it, because
it could contain important information still.

> So really, I guess I'm asking this community for feedback on two things:
>
> 1) Are these problems as common as my experiences imply, or am I just
> really unlucky?

I'd say you are slightly unlucky with pythons "email" library.
(It is really hard to say from the little I know.)

> 2) Is there any interest in trying to improve the standards?

There is always (some) interest, but it is hard work. 
Some of your assumptions do not seem to be shared in full by others.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20141125/3d9b568d/attachment.sig>