4 ms·

By and large the only way to prevent man in the middle and downgrade attacks is to use DNSSEC and DANE. Without that, an attacker can just filter out the STARTT

by phicoh 10y ago

By and large the only way to prevent man in the middle and downgrade attacks is to use DNSSEC and DANE. Without that, an attacker can just filter out the STARTTLS option in the SMTP EHLO response and the mail will be sent in plaintext. However, active attacks like downgrade attacks and TLS man in the middle are not popular for large scale surveillance. The reason is that it is easy to detect.

deno 10y ago
Or you could just use the existing standard TLS handshake instead of STARTTLS to upgrade the connection. DANE for this would be a step backwards, as you would just give governments the control of the PKI system. Edit: There is, however, something you could do with DNSCRYPT (or blockchain), that goes beyond just in-transit encryption. If you could publish your public key to a trust-worthy registry then we could have transparent body encryption. You could move email storage locally (with encrypted cloud backup), but still have DDoS resistant MXs.
- phicoh 10y ago
  For large scale monitoring of traffic, active attacks are very unattractive. If a government would manipulate dns on a large scale, that would cause a lot of trouble. For targeted attacks, using PGP is the way to go. Though it comes with the price of manual key management. It would be nice if somebody can do decentralised authentication at scale. But I haven't seen it in practice and I doubt it is going to happen at all.
  - deno 10y ago
    PGP works on individual message level. If email encryption is ever to get ubiquitous it needs a more comprehensive approach. It should start with a local email server that keeps all messages in an encrypted vault and can communicate in a secure manner with other clients that implement the “secure delivery” protocol (which would be indicated by being able to securely resolve the public key of target email address, and from an UI perspective by a special “Secure Send” send button). Manual key management will never succeed. Key discovery needs to be aggressively opportunistic yet secure. It’s the only way to go.
    - NoGravitas 10y ago
      Disclaimer: I'm only a consumer of cryptography, not a cryptographer. I have the feeling that secure email needs to be completely separate from SMTP; clients might be able to use both, in the same way that Signal will also use SMS when necessary. It should probably use a double-ratchet-based protocol, but cannot rely on centralization for contacts discovery and key exchange (because then it wouldn't be email-like). Among things that currently exist, it seems like the Matrix protocol[0] and OMEMO[1] seem basically suitable as a transport (both of them use the Olm protocol developed for Matrix, I believe). [0]: https://www.matrix.org/ https://www.matrix.org/ [1]: https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html
      - deno 10y ago
        You can absolutely replace SMTP but whatever you replace it with needs to be at least compatible with it. Lots of warnings, Insecure Email Ahead, but it needs to be compatible. I also don’t think email should be e2e by default. Next gen email will never get adopted if Gmail can’t index it. What you want is to give them the option of selling “Secure Cloud Email Vault.” Something that’s encrypted or partially encrypted (just body) on their servers, like Amazon is selling encryption for S3. But the protocol can also support fully local encrypted email (as detailed in my previous) for those that want that. Edit: Oh also for the actual cryptography there needs to be a way to give someone (like Court Order) decryption key to a single message. This avoids a lot of issues. Governments are not just going to let you deploy fully encrypted email by default.
        confounded 10y ago
        > I also don’t think email should be e2e by default. Next gen email will never get adopted if Gmail can’t index it. Fallback is fine; in the age of "surveillance capitalism" security for the moderately interested is the best we can hope for. > Governments are not just going to let you deploy fully encrypted email by default. What do you base this on? What would they do?
        10y ago

by phicoh 10y ago

deno 10y ago

Or you could just use the existing standard TLS handshake instead of STARTTLS to upgrade the connection. DANE for this would be a step backwards, as you would just give governments the control of the PKI system. Edit: There is, however, something you could do with DNSCRYPT (or blockchain), that goes beyond just in-transit encryption. If you could publish your public key to a trust-worthy registry then we could have transparent body encryption. You could move email storage locally (with encrypted cloud backup), but still have DDoS resistant MXs.

phicoh 10y ago
For large scale monitoring of traffic, active attacks are very unattractive. If a government would manipulate dns on a large scale, that would cause a lot of trouble. For targeted attacks, using PGP is the way to go. Though it comes with the price of manual key management. It would be nice if somebody can do decentralised authentication at scale. But I haven't seen it in practice and I doubt it is going to happen at all.
- deno 10y ago
  PGP works on individual message level. If email encryption is ever to get ubiquitous it needs a more comprehensive approach. It should start with a local email server that keeps all messages in an encrypted vault and can communicate in a secure manner with other clients that implement the “secure delivery” protocol (which would be indicated by being able to securely resolve the public key of target email address, and from an UI perspective by a special “Secure Send” send button). Manual key management will never succeed. Key discovery needs to be aggressively opportunistic yet secure. It’s the only way to go.
  - NoGravitas 10y ago
    Disclaimer: I'm only a consumer of cryptography, not a cryptographer. I have the feeling that secure email needs to be completely separate from SMTP; clients might be able to use both, in the same way that Signal will also use SMS when necessary. It should probably use a double-ratchet-based protocol, but cannot rely on centralization for contacts discovery and key exchange (because then it wouldn't be email-like). Among things that currently exist, it seems like the Matrix protocol[0] and OMEMO[1] seem basically suitable as a transport (both of them use the Olm protocol developed for Matrix, I believe). [0]: https://www.matrix.org/ https://www.matrix.org/ [1]: https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html
    - deno 10y ago
      You can absolutely replace SMTP but whatever you replace it with needs to be at least compatible with it. Lots of warnings, Insecure Email Ahead, but it needs to be compatible. I also don’t think email should be e2e by default. Next gen email will never get adopted if Gmail can’t index it. What you want is to give them the option of selling “Secure Cloud Email Vault.” Something that’s encrypted or partially encrypted (just body) on their servers, like Amazon is selling encryption for S3. But the protocol can also support fully local encrypted email (as detailed in my previous) for those that want that. Edit: Oh also for the actual cryptography there needs to be a way to give someone (like Court Order) decryption key to a single message. This avoids a lot of issues. Governments are not just going to let you deploy fully encrypted email by default.
      - confounded 10y ago
        > I also don’t think email should be e2e by default. Next gen email will never get adopted if Gmail can’t index it. Fallback is fine; in the age of "surveillance capitalism" security for the moderately interested is the best we can hope for. > Governments are not just going to let you deploy fully encrypted email by default. What do you base this on? What would they do?
        10y ago