Inline-encryption, encryption failure when storing sent mails

Inline-encryption, encryption failure when storing sent mails

[Simon Hirscher]

Hey there,

I'm quite new to notmuch and have two questions regarding the state of
mail encryption:

1. Support for inline-encryption
As far as I can see, so far only encrypted mails with PGP/MIME are
supported. Couldn't notmuch also support text/plain messages that
contain PGP-encrypted messages by scanning for "^-----BEGIN\ PGP\
(SIGNED\ )?MESSAGE"? – as suggested in a previous message to this
mailing list (id:87zl3az8mm.fsf@lillypad.riseup.net; web view:
http://notmuchmail.org/pipermail/notmuch/2010/001542.html). The reason
why I think it is necessary to support inline-encrypted messages is
that e.g. Thunderbird defaults to text/plain instead of PGP/MIME.

2. This is not necessarily related to notmuch itself but rather to
message-mode: Why are the mails that are fcc'ed to my sent-folder
encrypted with the recipient's key (instead of my own or simply no
key)? I.e. why can't I read my own mails? Is there any way to make
this work?

Thanks for your help,

Simon

Re: Inline-encryption, encryption failure when storing sent mails

[David Bremner]

Simon Hirscher <public@simonhirscher.de> writes:

> Hey there,
>
> I'm quite new to notmuch and have two questions regarding the state of
> mail encryption:
>
> 1. Support for inline-encryption As far as I can see, so far only
> encrypted mails with PGP/MIME are supported. Couldn't notmuch also
> support text/plain messages that contain PGP-encrypted messages by
> scanning for "^-----BEGIN\ PGP\ (SIGNED\ )?MESSAGE"? – as suggested in
> a previous message to this mailing list
> (id:87zl3az8mm.fsf@lillypad.riseup.net; web view:

If someone feels inspired to work on this, maybe 

   notmuch-wash-convert-inline-patch-to-part

(in notmuch-watch.el) might be a reasonable place to start.

> 2. This is not necessarily related to notmuch itself but rather to
> message-mode: Why are the mails that are fcc'ed to my sent-folder
> encrypted with the recipient's key (instead of my own or simply no
> key)? I.e. why can't I read my own mails? Is there any way to make
> this work?

What about setting this on the gpg level with the "encrypt-to" option?
Setting the emacs variable mml2015-encrypt-to-self seems like it ought
to work, but it seems to need some other settings as well. Perhaps have
a look at the customization group 'mime-security'.

d

Re: Inline-encryption, encryption failure when storing sent mails

[Simon Hirscher]

On Fri, Aug 16, 2013 at 10:02 AM, David Bremner <david@tethera.net> wrote:
> What about setting this on the gpg level with the "encrypt-to" option?
> Setting the emacs variable mml2015-encrypt-to-self seems like it ought
> to work, but it seems to need some other settings as well. Perhaps have
> a look at the customization group 'mime-security'.

Thanks, this was exactly what I was looking for! Although, there seems
to be a pitfall regarding recipients that I don't have a public key
for: If I choose to skip the encryption when sending the message, it
will still be encrypted with my own public key, hence the recipient
won't be able to read it. In that case it's obviously better to remove
the encryption tag from the message body before sending.

Re: Inline-encryption, encryption failure when storing sent mails

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

On 08/16/2013 04:02 AM, David Bremner wrote:
> Simon Hirscher <public@simonhirscher.de> writes:
> 
>> 1. Support for inline-encryption As far as I can see, so far only
>> encrypted mails with PGP/MIME are supported. Couldn't notmuch also
>> support text/plain messages that contain PGP-encrypted messages by
>> scanning for "^-----BEGIN\ PGP\ (SIGNED\ )?MESSAGE"? – as suggested in
>> a previous message to this mailing list
>> (id:87zl3az8mm.fsf@lillypad.riseup.net; web view:
> 
> If someone feels inspired to work on this, maybe 
> 
>    notmuch-wash-convert-inline-patch-to-part
> 
> (in notmuch-watch.el) might be a reasonable place to start.

if anyone does feel inclined to work on this, please consider that
dealing cleanly an inline-signed message has a number of serious
problems, not least of which is the Content-Type.

I've been meaning to write this up more cleanly, but a summary here will
have to do for now:

The MIME Content-Type header for an inline-PGP-signed e-mail message is
not signed.  This means that an attacker can replay a signed message
while undetectably changing the Content-Type.  One example of such an
attack is to leave the base Content-Type as text/plain but to switch
charsets -- the same bytestream can then be interpreted differently.

For example, depending on the charset, the same bytestream can be
represented as:

 The rental is €13/week for unit 7.

[charset=big5]

or:

 The rental is £ב13/week for unit 7.

[charset=iso-8859-8]

since 1GBP = 1.17EUR, this represents a change of 17% in the value of
the signed message while retaining the signature's validity :P

Given that you don't have cryptographically-reliable Content-Type
information, will you be comfortable indicating that the message is
actually signed?

Also, inline-signed messages may not span the entire part.  That is, a
message could have a bit of unsigned text above or below the
inline-signature.  The current user-facing UI in notmuch-emacs indicates
whether each part is individually signed or not.  How would
notmuch-emacs indicate reliably to the user that only a portion of the
part is signed?

In short: inline PGP is a mess, and existing implementations which try
to cope with it have severe shortcomings.  I'd rather avoid introducing
new types of failure to notmuch.

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1027 bytes --]

Re: Inline-encryption, encryption failure when storing sent mails

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Tue 2013-08-20 13:03:27 -0400, Daniel Kahn Gillmor wrote:
> I've been meaning to write this up more cleanly, but a summary here will
> have to do for now:
>
> The MIME Content-Type header for an inline-PGP-signed e-mail message is
> not signed.  This means that an attacker can replay a signed message
> while undetectably changing the Content-Type.  One example of such an
> attack is to leave the base Content-Type as text/plain but to switch
> charsets -- the same bytestream can then be interpreted differently.

I've finally written this up, with a demonstration.  I'm hosting it here
for now:

   https://dkg.fifthhorseman.net/notes/pgp-inline-harmful/

i hope this is useful for future discussions about inline PGP.

Please let me know if you see any problems with the text or if you have
any questions.

   --dkg

[-- Attachment #2: Type: application/pgp-signature, Size: 948 bytes --]