4 ms·

> Given that, why would it make sense for a service to assume that publishing a key signals that they should use it by default for a given communication channel

> Given that, why would it make sense for a service to assume that publishing a key signals that they should use it by default for a given communication channel? Why else would one publish a key and make it discoverable, if not that it be used?

UberFly 2y ago
I think the point is that it isn't an opt-in process as it should be. The default shouldn't be "if it exists use it".
- layer8 2y ago
  And yet that’s how browers use TLS. If you enter an HTTP address, they switch it to HTTPS when available, without asking the user “do you want to encrypt your access to this website?” each time.
kazinator 2y ago
For example, so that they could sign documents with the private key and have people be able to validate them. Another situation might be that, yes, the user wants encrypted mails, but are debugging their setup, part of which activity is uploading their key to openpgp.org. Until they get their stuff working, they don't want encrypted mails from the wild. A related situation might be that something breaks in the setup of a user who receives encrypted mails. They'd like to pause them and get regular mails, without the hassle of deleting the key.
noahtallen 2y ago
It’s used for more than just email. For example, you can sign packages on for Pacman on Arch Linux with GPG (https://wiki.archlinux.org/title/Pacman/Package_signing https://wiki.archlinux.org/title/Pacman/Package_signing), and they have you configure public key servers, which includes openpgp. Now, if I had set that up for package signing and other personal uses (like SSH keys, git commit signing, etc), that doesn’t mean I have my email set up to be encrypted. You should 100% be able to set a flag on the key server what you are set up to automatically receive using the key.
- aborsy 2y ago
  There is a key for encryption, signing, authentication and certification in OpenPGP. The flags are C, E, S, A. The use cases are separate. Perhaps another flag for automatic vs non automatic would help.
  - jsjohnst 2y ago
    Encryption is not just for encrypted emails.
    - soraminazuki 2y ago
      In theory. In practice, published PGP encryption subkeys has only seen adoption in emails. Besides, is the criticism that people are using published keys for email? It seems people are outraged that they received encrypted data using keys that they themselves advertised. The specific medium for data transfer doesn’t seem to matter here.
    - nulbyte 2y ago
      There are separate flags for communications (like email) and storage (like files). https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....
      - Macha 2y ago
        Great, but while the encryption vs signing choice is presented by common software (albeit in a way that does not make this consequence clear), it completely does not present the encrypt for communication and encrypt for storage options.
jsnell 2y ago
There are multiple uses for keys. I've published a key so that people can verify the signatures on some software releases. I don't expect anyone to try sending me an email encrypted with that key. And I really wouldn't expect such an email to work.
- Spivak 2y ago
  Yep, same. I find it funny that I'm apparently un-emailable by anyone on Proton. Good thing no one actually uses email for communication.
- bananskalhalk 2y ago
  And that is why there is different types of subkeys, which you are told about when generating the keys, and every "getting started" guide I've found. If you don't want to receive encrypted emails, don't share a subkey for encrypting email?
  - akerl_ 2y ago
    What's the subtype that's for encrypting emails? Last I looked, there's a subtype for encryption, with no specificity for what medium.
    - nulbyte 2y ago
      Not for email specifically, but there is a flag for encrypted communications and another for signing. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.... I believe separate keys for encryption and signing is the default in most implementations.
      - akerl_ 2y ago
        Sure, but there are things for encryption other than email. Publishing an encryption key does not imply that emails sent to me should be encrypted to that key.
franga2000 2y ago
So people in situations with a specific need for extra security can use them. When publishing it, this meant anyone who 1) explicitly joined the PGP ecosystem and has some understanding of it and 2) explicitly enabled encryption for this specific email or recipient. Neither are the case with what Proton is doing. Seriously Proton, just add a god damn prompt! And while you're at it, submit an RFC for a "please use by default" field in certs. Bonus points for a "this key is on a yubikey in a safe so if you use it you better have RCE in production to report" field as well or, hell, just a "key description" text field that clients can show the sender before using the key.
- twiss 2y ago
  Our goal is to make email encryption more usable and less niche, and not only for "situations with a specific need for extra security" - because people shouldn't have to think about which of their emails are and aren't security- or privacy-sensitive. Could you imagine if individual users had to opt-in to using TLS? Nobody would use it. The large push for using TLS everywhere has helped internet security a lot. Enabling the use of OpenPGP everywhere would also help much more than serving the use case of "this key is on a yubikey in a safe", because almost nobody is going to do that anyway.
- layer8 2y ago
  Would you also make TLS opt-in for each website?
  - akerl_ 2y ago
    TLS is opt-in for each website. If a web server doesn't specifically listen with a TLS certificate, users don't connect with one. Browsers will often attempt that connection, and then tell the user ~"Hey we tried to connect with HTTPS, but the server didn't respond. Do you want to try an unencrypted connection" But there's no case where Chrome will look and see "oh look, akerl has published a cert on this other site, we're going to just send traffic encrypted to that cert when we connect to his website".
    - 2y ago
watwut 2y ago
Usually by random action completely unrelated to emails they forgot about a few years ago.

UberFly 2y ago

I think the point is that it isn't an opt-in process as it should be. The default shouldn't be "if it exists use it".

layer8 2y ago
And yet that’s how browers use TLS. If you enter an HTTP address, they switch it to HTTPS when available, without asking the user “do you want to encrypt your access to this website?” each time.

kazinator 2y ago

For example, so that they could sign documents with the private key and have people be able to validate them. Another situation might be that, yes, the user wants encrypted mails, but are debugging their setup, part of which activity is uploading their key to openpgp.org. Until they get their stuff working, they don't want encrypted mails from the wild. A related situation might be that something breaks in the setup of a user who receives encrypted mails. They'd like to pause them and get regular mails, without the hassle of deleting the key.

noahtallen 2y ago

It’s used for more than just email. For example, you can sign packages on for Pacman on Arch Linux with GPG (https://wiki.archlinux.org/title/Pacman/Package_signing https://wiki.archlinux.org/title/Pacman/Package_signing), and they have you configure public key servers, which includes openpgp. Now, if I had set that up for package signing and other personal uses (like SSH keys, git commit signing, etc), that doesn’t mean I have my email set up to be encrypted. You should 100% be able to set a flag on the key server what you are set up to automatically receive using the key.

aborsy 2y ago
There is a key for encryption, signing, authentication and certification in OpenPGP. The flags are C, E, S, A. The use cases are separate. Perhaps another flag for automatic vs non automatic would help.
- jsjohnst 2y ago
  Encryption is not just for encrypted emails.
  - soraminazuki 2y ago
    In theory. In practice, published PGP encryption subkeys has only seen adoption in emails. Besides, is the criticism that people are using published keys for email? It seems people are outraged that they received encrypted data using keys that they themselves advertised. The specific medium for data transfer doesn’t seem to matter here.
  - nulbyte 2y ago
    There are separate flags for communications (like email) and storage (like files). https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....
    - Macha 2y ago
      Great, but while the encryption vs signing choice is presented by common software (albeit in a way that does not make this consequence clear), it completely does not present the encrypt for communication and encrypt for storage options.

jsnell 2y ago

There are multiple uses for keys. I've published a key so that people can verify the signatures on some software releases. I don't expect anyone to try sending me an email encrypted with that key. And I really wouldn't expect such an email to work.

Spivak 2y ago
Yep, same. I find it funny that I'm apparently un-emailable by anyone on Proton. Good thing no one actually uses email for communication.
bananskalhalk 2y ago
And that is why there is different types of subkeys, which you are told about when generating the keys, and every "getting started" guide I've found. If you don't want to receive encrypted emails, don't share a subkey for encrypting email?
- akerl_ 2y ago
  What's the subtype that's for encrypting emails? Last I looked, there's a subtype for encryption, with no specificity for what medium.
  - nulbyte 2y ago
    Not for email specifically, but there is a flag for encrypted communications and another for signing. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21 https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.... I believe separate keys for encryption and signing is the default in most implementations.
    - akerl_ 2y ago
      Sure, but there are things for encryption other than email. Publishing an encryption key does not imply that emails sent to me should be encrypted to that key.

franga2000 2y ago

So people in situations with a specific need for extra security can use them. When publishing it, this meant anyone who 1) explicitly joined the PGP ecosystem and has some understanding of it and 2) explicitly enabled encryption for this specific email or recipient. Neither are the case with what Proton is doing. Seriously Proton, just add a god damn prompt! And while you're at it, submit an RFC for a "please use by default" field in certs. Bonus points for a "this key is on a yubikey in a safe so if you use it you better have RCE in production to report" field as well or, hell, just a "key description" text field that clients can show the sender before using the key.

twiss 2y ago
Our goal is to make email encryption more usable and less niche, and not only for "situations with a specific need for extra security" - because people shouldn't have to think about which of their emails are and aren't security- or privacy-sensitive. Could you imagine if individual users had to opt-in to using TLS? Nobody would use it. The large push for using TLS everywhere has helped internet security a lot. Enabling the use of OpenPGP everywhere would also help much more than serving the use case of "this key is on a yubikey in a safe", because almost nobody is going to do that anyway.
layer8 2y ago
Would you also make TLS opt-in for each website?
- akerl_ 2y ago
  TLS is opt-in for each website. If a web server doesn't specifically listen with a TLS certificate, users don't connect with one. Browsers will often attempt that connection, and then tell the user ~"Hey we tried to connect with HTTPS, but the server didn't respond. Do you want to try an unencrypted connection" But there's no case where Chrome will look and see "oh look, akerl has published a cert on this other site, we're going to just send traffic encrypted to that cert when we connect to his website".
  - 2y ago

watwut 2y ago

Usually by random action completely unrelated to emails they forgot about a few years ago.