email culture (Re: WKD: conveying intent of encrypt-by-default?)
Am Donnerstag 13 Oktober 2022 23:50:33 schrieb Phil Pennock via Gnupg-users: > We need encryption _available_, but culturally > "encrypt-by-default" is not going to fly. In some cultures I hope (and guess) that it will fly. > Almost all email usage locally is Gmail, with the browser app or the > official Gmail mobile apps. That is not going to change. I wonder what could be done (in your local culture but also in other environments) to make reading encrypted emails better. E.g. have your users tried Mailvelope? https://mailvelope.com/en/ > This is about using encrypted content being a PITA for most > people. Somehow this shows how local and good native email clients could be better. As a long term email user a good email client makes me more productive and those clients can usually deal with encrypted email nicely (so it is not a hump at all, just a bit of setup once every few years). How could be get there for more people? Regards Bernhard -- https://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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD: conveying intent of encrypt-by-default?
Hello > Getting clients to respect this setting if published in WKD (or that the > lack of it means "do not encrypt by default") is an entirely different > subject, of course. And i know you said "no Protonmail rants" so i > won't call them out specifically here, but MUA developers generally > really do need to take the ecosystem effects of their choices seriously. > Any MUA that promiscuously encrypts *by default* to someone who has not > clearly indicated that they are comfortable with every inbound message > being encrypted is inviting that user to see encrypted e-mail as a > hindrance and an annoyance. That's not a great way to spread the > capability of people actually being able to use encrypted mail when it > matters, or to help people through a process of gradual adoption. Yes, I use protonmail, beside others. I opened an testaccount with mailbox.org, which offers you to encrypt all incoming messages with your public key if you specify it in the settings with their no-re...@mailbox.org private key. I have also tutanota, as it offers easily to send encrypted emails through an agreed password. Still searching the best way to go where I have all sent emails encrypted locally as well even they the mail to the receiver can't be encrypted. At which point are you willing to compromise? If course it is not ideal if proton has even the private key even without entering a passphrase for it. But they do it with the intention to get more encrypted mails on the transport. Oh dear I should meet you guys and discuss in person. Many questions around, I certainly do not best-practice but take it more and more easier this topic. If I allow mailbox.org to encrypt all my messages then i do so intentionally. protonmails are encrypted too, but I always see them cleartext as the pgp-stuff as handled in the background unknowingly to the user. > We have to have a sensible means of key discovery for exchanging > encrypted mail _when the situation warrants it_, such as distributing > sensitive data or receiving security reports. This is not about > signing. This is about using encrypted content being a PITA for most > people. Thunderbird has an autodiscovery feature to search for public keys. > It is not hyperbole to say that this one issue has done more to drive > and professional service operators". TLS for SMTP is not end-to-end, > but it turns out to be "good enough" for most daily usage, particularly > within a domain or with a few business partners. I just had cryptography in my bachelor and the teacher said the way to go is not TLS between servers as the mails still could be read. And that it's likely not gonna be implemented. Yes, right in the sense as the mail still can be read on the mailserver, but it would still help so they can't just get read. But first the servers should shut down TLS1.0/1.1; still too many with that protocol around. My two cents.. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD: conveying intent of encrypt-by-default?
On 2022-10-04 at 20:00 -0400, Daniel Kahn Gillmor wrote: > Autocrypt's focus is ubiquitous deployment of keying material (in the > form of OpenPGP certificates) so that people *can* encrypt when sending > mail. We found that one of the big risks is that a peer might > *automatically* encrypt when a cert is available, which becomes > burdensome for a user who does not have the ability to easily decrypt > messages. We don't want burdened users to stop distributing their cert > entirely because of this annoyance or frustration. This. > Getting clients to respect this setting if published in WKD (or that the > lack of it means "do not encrypt by default") is an entirely different > subject, of course. And i know you said "no Protonmail rants" so i > won't call them out specifically here, but MUA developers generally > really do need to take the ecosystem effects of their choices seriously. > Any MUA that promiscuously encrypts *by default* to someone who has not > clearly indicated that they are comfortable with every inbound message > being encrypted is inviting that user to see encrypted e-mail as a > hindrance and an annoyance. That's not a great way to spread the > capability of people actually being able to use encrypted mail when it > matters, or to help people through a process of gradual adoption. Exactly this. We need encryption _available_, but culturally "encrypt-by-default" is not going to fly. Almost all email usage locally is Gmail, with the browser app or the official Gmail mobile apps. That is not going to change. We have to have a sensible means of key discovery for exchanging encrypted mail _when the situation warrants it_, such as distributing sensitive data or receiving security reports. This is not about signing. This is about using encrypted content being a PITA for most people. The clients encrypting all mail by default are killing the use of OpenPGP and MIME-integrated PGP-encrypted email locally. It's another hammer in the coffin-lid of PGP's reputation as a reasonable technical solution for the problem spaces we care about. It is not hyperbole to say that this one issue has done more to drive the use of "age" encryption (with copy/paste into and out of emails as intact ASCII-armored blobs) than anything else. And age armored ciphertext pasted into Slack. It might seem clunky, but it works reliably and it aligns with cultural expectation of "only use this for things which really need the protection, otherwise just rely upon TLS and professional service operators". TLS for SMTP is not end-to-end, but it turns out to be "good enough" for most daily usage, particularly within a domain or with a few business partners. -Phil ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD: conveying intent of encrypt-by-default?
Hi Phil, To clarify: Why do you put keys intended only for signing into the WKD? The only purpose of the WKD is to discover keys used to encrypt outgoing data/mail. To verify a signature the WKD does not really help because there is no way to look up the key by fingerprint. Well, one of the fallbacks is: /* If the above methods didn't work, our next try is to retrieve the * key from the WKD. This requires that WKD is in the AKL and the * Signer's UID is in the signature. */ However, to be able to do this, the signer needs to specify the signing key by NAME (e.g. w...@gnupg.org) and not key fingerprint or keyid (e.g. AEA84EDCF01AD86C4701C85C63113AE866587D0A) as suggested. Or to use the --sender option. Is this your use-case? Makes some sense to me. Summary of options: 1. Upload sign-only keys (strip the encryption subkey). You can't use the Web Key Service in this case. You have to resort to another mechanism like build a local mirror and rsync it. 2. Add a notation to the key not to use the encryption key without asking. This requires all clients to understand this notation and act acordingly. 3. Add a WKD policy not to use the key for opportunistic encryption. Also needs cleint changes. 4. A variant of 1 which strips the encryption subkey after the publication has been confirmed. This can be done with a WKS protocol extension. Advantage is that it can be done on a key by key base. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD: conveying intent of encrypt-by-default?
Phil Pennock via Gnupg-users wrote: [...] Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. Simple option if most users at your site will be generating PGP signatures but not running PGP-capable MUAs: generate sign-only keys and put those in WKD. You would need a second mechanism for distributing the encryption-permitted keys for those users who need them, but the encryption keys could in turn be signed with the WKD sign-only keys to prevent a man-in-the-middle attack. -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD: conveying intent of encrypt-by-default?
On Mon, 3 Oct 2022, Phil Pennock via Gnupg-users wrote: Folks, I setup WKD for work a while back, to publish the PGP keys for those who had them. Then in November I removed the first key because it was causing Protonmail users to keep sending encrypted to the recipient and a lot of his communications turned out to be with Protonmail users. Now we've had this happening again, with someone else, and one very plausible outcome at this point is that we remove almost everyones' keys from WKD, leaving only those who sign security advisories, because WKD and the ecosystem right now is causing bigger problems than it solves. I think that there's a perfectly reasonable conflation of semantic intent. I'm not sure what the solution is, although I'm thinking that _perhaps_ the answer is to extend the allowed values in the "policy" file, to convey intent to a different audience than those uploading keys. Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. While Protonmail is the triggering party here, I don't think that they're at fault: for their model, what they've set up is probably a reasonable implementation. So please, no rants about Protonmail. Am I right in thinking that WKD was not really intended to be a trigger for opportunistic upgrade to PGP-encryption for messaging? Does it seem reasonable to add a directive to WELLKNOWN/policy, so that any WKD client can see what a general domain policy is? I could see individual users having other preferences, and I guess there's no reason that an additional binary PGP packet, not signed by the key, couldn't be served up together with the key from the WKD server. But that's more extensive coding to handle and interpret. Tentatively, perhaps: email-encrypt-by-default: yes email-encrypt-by-default: no and then if not present, then the intent is unspecified. We would then add "email-encrypt-by-default: no" and then the WKD draft could clarify as an implementation consideration that "availability of the key does not imply routine use of the key is desired". -Phil Hi Phil, ignoring your proposal (it sounds valid to me), would it be an option to make the key a pure signing key? What's the use case to have an encryption key but not receive encrypted email by default? regards, Erich ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
WKD: conveying intent of encrypt-by-default?
Folks, I setup WKD for work a while back, to publish the PGP keys for those who had them. Then in November I removed the first key because it was causing Protonmail users to keep sending encrypted to the recipient and a lot of his communications turned out to be with Protonmail users. Now we've had this happening again, with someone else, and one very plausible outcome at this point is that we remove almost everyones' keys from WKD, leaving only those who sign security advisories, because WKD and the ecosystem right now is causing bigger problems than it solves. I think that there's a perfectly reasonable conflation of semantic intent. I'm not sure what the solution is, although I'm thinking that _perhaps_ the answer is to extend the allowed values in the "policy" file, to convey intent to a different audience than those uploading keys. Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. While Protonmail is the triggering party here, I don't think that they're at fault: for their model, what they've set up is probably a reasonable implementation. So please, no rants about Protonmail. Am I right in thinking that WKD was not really intended to be a trigger for opportunistic upgrade to PGP-encryption for messaging? Does it seem reasonable to add a directive to WELLKNOWN/policy, so that any WKD client can see what a general domain policy is? I could see individual users having other preferences, and I guess there's no reason that an additional binary PGP packet, not signed by the key, couldn't be served up together with the key from the WKD server. But that's more extensive coding to handle and interpret. Tentatively, perhaps: email-encrypt-by-default: yes email-encrypt-by-default: no and then if not present, then the intent is unspecified. We would then add "email-encrypt-by-default: no" and then the WKD draft could clarify as an implementation consideration that "availability of the key does not imply routine use of the key is desired". -Phil signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
