Protect email experience not Subject:s (hypothesis, draft)

[Andre Heinecke]

Hi,

On Friday 29 January 2021 17:52:25 CET Bernhard Reiter wrote:
> for many months now, my feeling is growing that
> 
>   encrypted subject headers in emails
>   shift the security balance in the wrong direction.

I share that feeling. My goal that encrypted mails do not feel much different 
from unencrypted mails is made harder by subject encryption. So in a security 
VS. usability standpoint that assumes that if usability is bad, users will not 
encrypt mails or at least fewer mails I come to the same conclusion.

This discussion is very relevant for me because GpgOL is starting to include 
protected-headers mime parts with the next version to transfer To and CC 
information. Putting the subject into it would be easy but it's more of a 
policy decision if we want to encourage or discourage this.

> If it is understood that the header section is like notes
> on a paper envelope, needed for mail transport and to be able to be seen by 
> the transporting agents, this can be used to assess what can be learned
> from it. And then common ways of distracting from the contents can be used.
> (I write 'common ways', because this is a core of my concept about how to
> get  end-to-end encryption - especially email - more usable: People already
> know  social ways how to deal with different levels of confidentiality.
> Sofware application need not to hide it the aspects too much.)

I agree with the mental image of notes on an envelope, this is also how I try 
to explain the Subject. We could probably try to explain this better. E.g. by 
showning this as information once the first encrypted mail is sent.

> == Valid use cases?
> Where the "Subject:" is a lot more than a writing on the envelope.
> 
>  * Example: a roundup-tracker fully run with OpenPGP/MIME mails,
>    by default it changes the title of an issue and there can be
>    commands to control the issue in the subject. (Also an example
>    where backwards compatiblity failed.)
> 
> Implementation idea: per recipient (group) settings to explicitely
> enable encrypted subjects for those groups and contexts where it is
> known to be more useful.

I'm not sure, if the user configures such rules by themself they already have 
an awareness that they don't really need automation for this. And if an Admin 
preconfigures this for a whole instiution we have the bad user expierence that 
the subject is "sometimes" encrypted. That would be even more confusion.

Currently for GpgOL I'm tending to a global option to encrypt the subject 
which would be off by default and show a warning when it is activated that 
recipients will only see "..." in their message list and threading etc. will 
be broken. Just having the option and a warning related to the option could 
raise awareness about the issue.


Best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210201/a899fa10/attachment.sig>