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

[Daniel Kahn Gillmor]

On 11/25/2014 03:42 AM, Bernhard Reiter wrote:

> On Monday 24 November 2014 at 10:25:43, Bjarni Runar Einarsson wrote:

>> 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 also a violation of RFC 3156, which extends
https://tools.ietf.org/html/rfc2015#section-3

   Multipart/signed and multipart/encrypted are to be treated by agents
   as opaque, meaning that the data is not to be altered in any way [1].

Which goes all the way back to RFC 1847 from October 1995 :/

This is supposed to be http://bugs.python.org/issue1670765, which is
claimed to be resolved.

If it's not resolved, someone needs to let the python devs know about it.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141125/05c25ce5/attachment.sig>