Re: header protection drafts too early to implement (Re: Protect email experience not Subject:s (hypothesis, draft))
Am Freitag 12 März 2021 18:02:41 schrieb Bernhard Reiter: > To keep you in the loop, my main take-away so far: > It is not ready to be implemented yet, because If it is implemented, to me it makes sense to a) only implement one method, and this seems to be to wrap one full message in MIME, because it is most backwards compatible and proposed in the current draft. Thunderbird does implement a different outdated approach I believe (At least I've examined an email from Thunderbird/78.6.0) and I found Content-Type: multipart/mixed; boundary="."; protected-headers="v1") b) implement reading first and do not activate sending. This is something that Thunderbird should also fix. Implemententation for reading makes some sense to try out how the unaddressed usability problems will fare out. To send encrypted subjects now means losing information if an injected approach is used like Thunderbird seems to use. Best Regards, Bernhard -- 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
header protection drafts too early to implement (Re: Protect email experience not Subject:s (hypothesis, draft))
Took a few hours to read through the current version of Am Freitag 29 Januar 2021 17:52:25 schrieb Bernhard Reiter: > [3] https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ draft-ietf-lamps-header-protection-03 Last updated 2021-02-22 which also aims at OpenPGP/MIME mails. To keep you in the loop, my main take-away so far: It is not ready to be implemented yet, because a) it rightfully aims to proposed one method and leans towards wrapped message approach. b) the usability problems are not addressed, mainly how to display a mixed set up headers where some are signed-only, not protected or signed-and-encrypted, but also the complexity arising from this. Also what should happen if one of the signature do not validate, displaying this for each header field is something I cannot really imaging so far. c) the drawback of server filter and access and indexing problems with implementations (where email draws a lot of usability from) are unsolved. Overall, there is some good technical work in the document. Personally I feel it focusses on some aspects more than other aspects, missing a bit on the bigger picture. Best Regards, Bernhard -- 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
protected to: and cc: email infos (Re: Protect email experience not Subject:s (hypothesis, draft))
Am Montag 01 Februar 2021 12:32:03 schrieb Andre Heinecke via Gnupg-users: > 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. Did you write more about the use case somewhere? My thinkig is: the to: and cc: information would also be like addressing hints on an envelope (to stay in this picture) and there could be a usability downgrade if this infos goes into protected MIME headers for elder implementations. > Putting the subject into it would be easy but it's more > of a policy decision if we want to encourage or discourage this. One main concern I am thinking about is the grade and time frame of backwards compatibility. One main email advantage is that it is based on decentral standards, thus people can use diverse old (and stable) clients for a long time. Best Regards, Bernhard -- 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
Re: Protect email experience not Subject:s (hypothesis, draft)
Am Freitag, 29. Januar 2021, 17:52:25 CET schrieb Bernhard Reiter: > From an implementers point of view, protected headers seem to make > it more complicated and break some ways to implement good access > to emails. As Thunderbird as enabled "encrypted" subjects by default with 78 and additionally did not offer a way to disable this initially, it created a number of real world examples. Thunderbird forced this change on users, according to this https://support.mozilla.org/en-US/questions/1304451 there is only a hidden (expert) setting to disable it since 78.5.1. Mentioned drawback: * Breaks filtering for the using company. " It's very important for mail filtering rules to be able to read the subject without opening the mail first." Best Regards, Bernhard -- 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
Re: Protect email experience not Subject:s (hypothesis, draft)
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.HeineckeMail: bo...@gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 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
Protect email experience not Subject:s (hypothesis, draft)
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
