3 ms·

> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to

by md_ 5y ago

> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them. Surely it’s on me, if I wanted the content to be secret? > What metadata are you concerned about here? Subject lines? I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both. > Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated. As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do. > I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!

encryptluks2 5y ago
> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them. No matter what encryption you use, if your recipient gets compromised there is nothing you can do except don't sign the message with a published public key and send the message anonymously. Then, at least, it would be more difficult to trace back to you unless you include personally identifiable information in the encrypted message. > I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both. First, when it comes to traffic patterns I have no clue what that means. You can hide the recipient with GPG, so they have some plausible deniability as long as someone else doesn't have their secret key and passphrase. You can encrypt the subject line pending email client support to decrypt, but really it seems pointless. Might as well just say `hello` or `secure` in the subject line. I imagine you could also create an RFC to add an encrypted subject to the header if one doesn't exist already. > As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do. It doesn't have to be a lot of hassle. If I remember correctly, Keybase may have had something similar for messaging. It just hasn't been done because instead of using GPG, a lot of people want to implement something else, which is fine as long as it is secure. GPG is secure though which is why people throughout the intelligence community use it frequently and journalists that want security. Maybe for PFS something like age makes more sense, but GPG has been around and is more tried and tested. > think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely! GPG is usable and usably secure, if you know even some of the basics of what you're doing. Really, just looking through the docs on GPG's website provides a vast resource of information. It can be overwhelming for grandma, and yes sometimes the docs are confusing in certain areas, but it is not challenging for people in tech that have a little patience (doesn't require a lot). There certainly isn't anything stopping GPG from being the default except competing solutions. It has been pretty much the default for email security for some time.
- tptacek 5y ago
  The subject line is message text! It's message! That's literally what it is! It's baffling (and revealing) to see email encryption advocates downplay the fact that subjects are exposed in plaintext. The retcon here is that subjects are somehow intended as the unencrypted, public part of the message, as if that was a normal feature of a sealed letter. Go find the last letter you mailed someone (or try to remember; I know it's been awhile) and look on the envelope for the part where you wrote what the message was about.
  - encryptluks2 5y ago
    I explained ways to avoid this. Write `secure` for the subject and include the actual subject in the encrypted message. Propose an RFC to include an encrypted subject in the headers. Encrypted the subject line. I don't think this is valid considering that there are solutions.
    - tptacek 5y ago
      When you're at the point of making excuses for important parts of the message text being revealed in plaintext, the useful debate about email encryption is basically over.
      - encryptluks2 5y ago
        That is how email works. The subject isn't an important part of message text, the message is.
        tptacek 5y ago
        We agree about at least this much: this is, indeed, how email works.
    - akerl_ 5y ago
      What if instead of writing “secure” in the subject, I just don’t send the email and instead use Signal or WhatsApp where all the text is encrypted end to end? It’s not clear why it’s desirable to keep bolting things onto email in an attempt to somehow make it eventually match the security profile that we can already get by just using other existing options.

by md_ 5y ago

> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them. Surely it’s on me, if I wanted the content to be secret? > What metadata are you concerned about here? Subject lines? I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both. > Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated. As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do. > I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!

encryptluks2 5y ago

> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them. No matter what encryption you use, if your recipient gets compromised there is nothing you can do except don't sign the message with a published public key and send the message anonymously. Then, at least, it would be more difficult to trace back to you unless you include personally identifiable information in the encrypted message. > I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both. First, when it comes to traffic patterns I have no clue what that means. You can hide the recipient with GPG, so they have some plausible deniability as long as someone else doesn't have their secret key and passphrase. You can encrypt the subject line pending email client support to decrypt, but really it seems pointless. Might as well just say `hello` or `secure` in the subject line. I imagine you could also create an RFC to add an encrypted subject to the header if one doesn't exist already. > As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do. It doesn't have to be a lot of hassle. If I remember correctly, Keybase may have had something similar for messaging. It just hasn't been done because instead of using GPG, a lot of people want to implement something else, which is fine as long as it is secure. GPG is secure though which is why people throughout the intelligence community use it frequently and journalists that want security. Maybe for PFS something like age makes more sense, but GPG has been around and is more tried and tested. > think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely! GPG is usable and usably secure, if you know even some of the basics of what you're doing. Really, just looking through the docs on GPG's website provides a vast resource of information. It can be overwhelming for grandma, and yes sometimes the docs are confusing in certain areas, but it is not challenging for people in tech that have a little patience (doesn't require a lot). There certainly isn't anything stopping GPG from being the default except competing solutions. It has been pretty much the default for email security for some time.

tptacek 5y ago
The subject line is message text! It's message! That's literally what it is! It's baffling (and revealing) to see email encryption advocates downplay the fact that subjects are exposed in plaintext. The retcon here is that subjects are somehow intended as the unencrypted, public part of the message, as if that was a normal feature of a sealed letter. Go find the last letter you mailed someone (or try to remember; I know it's been awhile) and look on the envelope for the part where you wrote what the message was about.
- encryptluks2 5y ago
  I explained ways to avoid this. Write `secure` for the subject and include the actual subject in the encrypted message. Propose an RFC to include an encrypted subject in the headers. Encrypted the subject line. I don't think this is valid considering that there are solutions.
  - tptacek 5y ago
    When you're at the point of making excuses for important parts of the message text being revealed in plaintext, the useful debate about email encryption is basically over.
    - encryptluks2 5y ago
      That is how email works. The subject isn't an important part of message text, the message is.
      - tptacek 5y ago
        We agree about at least this much: this is, indeed, how email works.
  - akerl_ 5y ago
    What if instead of writing “secure” in the subject, I just don’t send the email and instead use Signal or WhatsApp where all the text is encrypted end to end? It’s not clear why it’s desirable to keep bolting things onto email in an attempt to somehow make it eventually match the security profile that we can already get by just using other existing options.