Memory Hole discussion / OpenPGP e-mail header protection

[Alexander Strobel]

Am 06.07.2015 um 09:55 schrieb Stefan Selbitschka:
> I split my implementation in three kind of headers "headers to 
> secure", "headers to remove" and "headers to replace". While the 
> first headers are put into the rfc822-headers part(s) the second 
> group are removed from message headers and the last group of headers 
> is set to a default value like "subject => "encrypted message".

> Question are:
> Should we remove headers?
> Should one or both be a user choice or do we deicide?
> ...

Does "headers to remove" mean that they are stripped from the email
completely? Even as I can understand the intention to do something lkike
this, I think this might be something which some MUAs arent able to
realize. I would not prefer such an explizit blacklisting.

> For the UI representation of protected headers I would make a green
> background for header fields that are protected and not manipulated, a
> red background if they are manipulated and standard transparent if a
> headers is not protected.

Using colors to communicate ok/error states is common, but bad usabilty
in my opinion. As colors might be displayed wrong (if you don't use
something like web safe colors), there are some people outside which are
color blind or live in a culture where the meaning of a color is
different from our understanding.
Because of this I would prefer icons and/or a textual representation.

> Do we implement this for PGP/MIME and Inline?
>
> My assumption in April was that we implement this only for PGP/MIME
> but since some of us like gpg4o can only to inline-pgp, I think we
> should do both. Is there a agreed MIME structure for the inline case >
or do we just use the same?

To implement this for PGP/MIME was our understanding too. We are able to
read PGP/MIME without problems. Creating RFC conform PGP/MIME in
contrast _is_ a problem for us, as Outlook/Exchange inserts an empty
MIME part and destroys the content-type of the email and the first empty
MIME part.
So you would all help gpg4o, gpg4win, Outlook Privacy Plugin, ... (i.e
everyone who has to communicate via MAPI with Outlook/Exchange), when
everyone might be able to interpret/read this "PGP/MIME" equivalent.

Defining a standard for protected-headers in INLINE messages might help
other webbased "clients" like Mailvelope and others to check whether a
mail has been modified on its way to the recipient(s). It think it won't
be a solution for encryption on these platforms as they don't have
access to the source of the emails nor they have (write) access to the
email headers.



Regards
 Alex Strobel
 www.gpg4o.com

Am 06.07.2015 um 09:55 schrieb Stefan Selbitschka:
> Hi,
> 
> I nearly finished my implementation in R2Mail2 and some questions 
> arose, I'd like to discuss with you, since I think if we all 
> implement this without a standard we should to the same ;).
> 
> Which headers are protected?
> 
> I split my implementation in three kind of headers "headers to 
> secure", "headers to remove" and "headers to replace". While the 
> first headers are put into the rfc822-headers part(s) the second 
> group are removed from message headers and the last group of headers 
> is set to a default value like "subject => "encrypted message".
> 
> In the singed only case removing headers make no sense but in the 
> encrypted case this could increase security against meta data 
> analysis.
> 
> At the moment I have following headers in the separate arrays: 
> HEADERS_TO_SECURE = { "from", "to", "cc", "subject", "message-id", 
> "references", "x-mailer", "in-reply-to", "reply-to" } 
> HEADERS_TO_REMOVE = { "references", "x-mailer", in-reply-to", 
> "reply-to" } HEADERS_TO_REPLACE = { "subject" => "Encrypted Message" 
> }
> 
> As long as I could see Enigmail didn't remove any headers at the 
> moment.
> 
> Question are: Should we remove headers? Which headers are protected 
> and removed or replaces by dummy values? Should one or both be a
> user choice or do we deicide?
> 
> 
> 
> What is the terminology and UI representation for the user?
> 
> How should we call the settings where we enable/disable the header 
> protection? "Protect Headers" => Yes/No.
> 
> For the UI representation of protected headers I would make a green 
> background for header fields that are protected and not manipulated, 
> a red background if they are manipulated and standard transparent if 
> a headers is not protected.
> 
> 
> 
> Do we implement this for PGP/MIME and Inline?
> 
> My assumption in April was that we implement this only for PGP/MIME 
> but since some of us like gpg4o can only to inline-pgp, I think we 
> should do both. Is there a agreed MIME structure for the inline case 
> or do we just use the same?
> 
> 
> regards - Stefan
> 
> 
>