Hello, for many months now, my feeling is growing that encrypted subject headers in emails shift the security balance in the wrong direction.
So I want to summarize and explore this hypothesis. Here are some draft thoughts and notes. Feedback welcome (either to me directly or on the list). Not sure yet, where to place all this, but in the best tradition I'll announce my intentions here and will follow up as I learn. Best Regards, Bernhard == Idea of protected headers. The subject of an email delives contents related to the body of the mail. To raise the confidentiality (as one aspect of security), it is proposed to do end-to-end encryption on the subject Header-Field. == Hypothesis The subject Header-Field is also meta data, needed to keep email usable. Or in other words: to support the availability aspect of security. Because email is the most popular decentral communication solution [5] compatibility with existing installations and existing ways of working for diverse user groups is more important than in other softwar contexts. From an implementers point of view, protected headers seem to make it more complicated and break some ways to implement good access to emails. Examples: * IMAP servers can search emails by subject. A feature that cannot be kept functional with inaccessible contents. * Fast access to filtering in clients by subject is broken, because it would mean indexes and indexes would need to come from a crypto secure store, one each per crypto context (private key). * There are many old or non-header-decrypting clients around, otherwise fine and stable. As observable metadata cannot be avoided totally, maybe the alternative to automating the Header-Fields is to help people manage the different levels of security they need per occasion. Thought experiment: 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.) As a consequence encrypting the subject of an email can be seen as contributing only very little to the confidentiality. The whole exchange has to done so that it looks unsuspicous anyway. Potential conclusion: Encrypted subject headers contribute a little bit to confidentiality, but they also lower availability for many cases (by the implementation complications). They should not be send by default. == 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. == Material [1] https://github.com/autocrypt/memoryhole archived in favour of [2] lists some alternatives and links elder discussions [2] https://github.com/autocrypt/protected-headers Old source code repo of [3]? [3] https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ "Header Protection for S/MIME draft-ietf-lamps-header-protection-02 (Last updated 2020-11-02)" also aiming at OpenPGP/MIME? [4] A widely spread version of Thunderbird v78 did not allow disabling the encryption of subjects. https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_can-i-disable-the-encryption-of-the-email-subject [5] Mahn, Jan, 2021, c't 2021/03 pp50-53 "Nichts zu verbergen? Sicher und vertraulich kommunizieren: Ein Grundrecht" https://www.heise.de/select/ct/2021/3/2030913061555053970 -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
