17 ms·

Address Verification and Full PGP Support

174 points by johnnycarcin 8y ago

kradle 8y ago
relevant: https://blog.cryptographyengineering.com/2018/05/17/was-the-efail-disclosure-horribly-screwed-up/ https://blog.cryptographyengineering.com/2018/05/17/was-the-...
- deleted 8y ago
  [deleted]
Sephr 8y ago
Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email. Webmail providers can implement read receipt privacy by requesting images from every email automatically on-delivery instead of on-read. Doing this for non-existent mailboxes also prevents mailbox enumeration.
- stevehawk 8y ago
  Potential there for a DOS attack isn't there? "hey look this server blindly downloads images".. Sends a million emails with a bunch of tiffs.
  - shuzchen 8y ago
    Not only would the server need to download the image, it would need to store it in perpetuity because the server would then be responsible for serving them to you (if your client makes any direct request you'll leak when you viewed the email, the trackers don't only track the first request). This is not something that is easy to implement.
    - deleted 8y ago
      [deleted]
  - jrockway 8y ago
    I don't really see this as a major problem. Just grab a reasonable number of bytes and disconnect. If a user does end up wanting to view the full TIFF, just say "this server is probably stealing your private information and you will also go over your storage quota by loading this image". If the user is OK with that, then download the image again. 99% of the time, the image is just a company logo in someone's email signature and takes essentially zero storage space or bandwidth to retrieve at receive time. For the special cases, just warn the user about the implications of downloading the image, and go do it if they ask.
    - bartbutler 8y ago
      This is basically the plan. There are some other concerns, notably bandwidth/space and, given it's untrusted input, thinking through all the other ways it could be abused. There will certainly be a byte limit.
  - Sephr 8y ago
    A Google security engineer confirmed to me that Google toyed with this idea but ultimately decided not to do it due to various partners not wishing to lose the ability to perform read receipt tracking. There are no unsolved technical reasons preventing this from being enabled in Gmail, only political reasons.
    - Jach 8y ago
      Huh, I was under the impression that Google started doing this years ago and didn't stop, and even tied it into spam analysis... Did your contact elaborate on the extent of their "toying" and any timelines? I guess I'll have to revisit some of my arguments -- a few years ago I successfully fought against adding a tracking pixel to an email template on the basis of read receipt hits not being valid hits a lot of the time (let alone never getting a hit despite being read due to images being off) due to providers like gmail pre-loading them (sometimes more than once at random times), so we should just use click-through metrics on links when the request comes with an authentication cookie.
      - Sephr 8y ago
        Google proxies and caches all external assets in emails through their own servers to hide your IP address, but they only do this on-read instead of on-delivery, which enables read receipt tracking.
- brightball 8y ago
  > Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email. I think those two things put together create a very, very niche use case. If I'm concerned about privacy, I don't turn on loading images by default. I'd be really curious to see the overlap in users who do.
  - Oi7ie6op 8y ago
    plus those who "need" to embed visible images (e.g. marketing insisting on the company logo in the footer) could use svg data uris now, so they're not really in conflict with blocking 3rd part content.
  - Sephr 8y ago
    > If I'm concerned about privacy, I don't turn on loading images by default The point is that you shouldn't have to do this, and can be afforded the same privacy while improving your user experience.
    - brightball 8y ago
      It can’t though. Whenever the image is loaded, by default or otherwise, the image itself can act as a read receipt. That’s how most email services track opens. If the server downloads the image for you, then the server has to store the image to prevent you from accessing it directly from the host. That creates cache time discussions, storage quote discussions, etc. Even if the image itself is proxied through a CDN, the time the image is accessed is still exposed.
      - disiplus 8y ago
        > That creates cache time discussions, storage quote discussions, etc. why cache time discussions, after initial download there is no need to download it again, email is not the browser, there is no expectation that the image in email will be the actual at the time of opening, the expectation is that the image is actual at the time of sending. and for storage you can use hash to not store duplicates, and probably save bandwith with optimization.
- bartbutler 8y ago
  Doing some sort of image proxy download in a safe and efficient way (which is not entirely trivial) is certainly part of the plan.
  - deleted 8y ago
    [deleted]
ddevault 8y ago
I spoke on Mastodon recently about Protonmail - it's a scam and I cannot recommend it to anyone. They own your email, they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false. Their security is also based on trusting ProtonMail, since they could easily siphon off plaintext at the SMTP level or secretly modify their JavaScript to exfiltrate your private keys from the web browser. Genuinely secure systems do not require you to trust their operators. >PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn’t belong to anybody, there is no single central server, and you aren’t forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source. This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.
- snowpanda 8y ago
  >they don't support open protocols including SMTP >they could easily siphon off plaintext at the SMTP level This doesn't make any sense.
  - Sir_Cmpwn 8y ago
    They don't support realying their user's outgoing mail through SMTP. They have to support server-to-server SMTP to receive incoming mail. The latter is where they encrypt incoming emails, but they could just as easily store the plaintext and you'd never know.
    - gruez 8y ago
      that limits it to the moment the email was received, which is still better than everyone else, where you can read the mail any time in the future.
marcrosoft 8y ago
Maybe the title should read "Email address verification and full PGP support". This should not be confused with real physical address verification.
Boulth 8y ago
It's nice to see their own keyserver. I wonder though if it wouldn't be more practical to support the Web Key Directory protocol [0]. WKD is both more secure than HKP (as it's always over HTTPS and authenticates user's domain), it's enabled by default in a growing number of email clients (Enigmail, GPG for Outlook, KMail) and providers (kernel.org [1], posteo.de), it's used by GPG when locating a key and the setup is incredibly easy (just put binary key in one location). (to check it out try `gpg --locate-key torvalds@kernel.org` in modern GnuPG) From my perspective it looks like a perfect match for ProtonMail for both use cases: exposing @protonmail.ch users' keys and fetching keys of contacts on other servers. [0]: https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD [1]: https://www.kernel.org/category/signatures.html https://www.kernel.org/category/signatures.html
- bartbutler 8y ago
  We'll probably do this soon, HKP is older and more broadly supported at the moment so it got built first.
  - Boulth 8y ago
    Got it, thanks for the reply and for considering modern features!
  - dane-pgp 8y ago
    That makes sense, thanks. I'd love to see support for RFC-7929 at some point too. https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929 It has the advantage of not relying on the Certificate Authority system, and not requiring a full web stack (which some email clients and servers wouldn't want to open themselves up to). DNSSEC also allows Authenticated Denial of Existence, so that unavailability of a server isn't treated as meaning the user doesn't have a key in the directory. For reference, this technology is also already supported by GnuPG and Posteo.de: https://posteo.de/en/blog/new-posteo-public-key-directory https://posteo.de/en/blog/new-posteo-public-key-directory
    - Promarged 8y ago
mirimir 8y ago
This is very good news! It's also great to have https://protonirockerxow.onion/ https://protonirockerxow.onion/ :) But I have a suggestion. If I hit https://protonmail.com/ https://protonmail.com/ via Tor, there's no warning to use the .onion address. Except for an "Onion Site" link at the bottom. And after I recently created a free account via Tor at https://protonmail.com/ https://protonmail.com/, I got that either SMS verification or a credit/debit card number was required for activation. Gak! But using https://protonirockerxow.onion/ https://protonirockerxow.onion/, there's no authentication requirement for activation. So perhaps there could be an alert when connecting to https://protonmail.com/ https://protonmail.com/ via Tor. As I recall, Bitmixer or Helix Light used to do that. Or maybe just put the .onion address near the top of the front page.
- deftnerd 8y ago
  There is a draft IETF standard to handle this! It uses a new "alt-svc" header that lets you specify alternative URLS to access a domain. Cloudflare is using it for their 1.1.1.1 service. If you look at the headers at https://tor.cloudflare-dns.com/ https://tor.cloudflare-dns.com/, you get alt-svc: h2="dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443"; ma=315360000; persist=1 I don't know if the Tor Browser Bundle handles this yet but its a great idea! https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-tor/ https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over... https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10 https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10
  - mirimir 8y ago
    It looks like HTTP/2 (and specifically alt-svc) is explicitly disabled in Tor browser.[0] > Design Goal: SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore, all associated means that could be used for cross-domain user tracking (alt-svc headers come to mind) MUST adhere to this design principle as well. > Implementation status: SPDY and HTTP/2 are currently disabled by setting the Firefox preferences network.http.spdy.enabled, network.http.spdy.enabled.v2, network.http.spdy.enabled.v3, network.http.spdy.enabled.v3-1, network.http.spdy.enabled.http2, network.http.spdy.enabled.http2draft, network.http.altsvc.enabled, and network.http.altsvc.oe to false. Rather than redirection, I was thinking just a fork in rendering, if the user's IP is a Tor exit. 0) https://www.torproject.org/projects/torbrowser/design/ https://www.torproject.org/projects/torbrowser/design/
mikedilger 8y ago
For the other perspective, fastmail has a good write-up on why they don't offer PGP: https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/ https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/

174 points by johnnycarcin 8y ago

relevant: https://blog.cryptographyengineering.com/2018/05/17/was-the-efail-disclosure-horribly-screwed-up/ https://blog.cryptographyengineering.com/2018/05/17/was-the-...

deleted 8y ago
[deleted]

Sephr 8y ago

Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email. Webmail providers can implement read receipt privacy by requesting images from every email automatically on-delivery instead of on-read. Doing this for non-existent mailboxes also prevents mailbox enumeration.

stevehawk 8y ago
Potential there for a DOS attack isn't there? "hey look this server blindly downloads images".. Sends a million emails with a bunch of tiffs.
- shuzchen 8y ago
  Not only would the server need to download the image, it would need to store it in perpetuity because the server would then be responsible for serving them to you (if your client makes any direct request you'll leak when you viewed the email, the trackers don't only track the first request). This is not something that is easy to implement.
  - deleted 8y ago
    [deleted]
- jrockway 8y ago
  I don't really see this as a major problem. Just grab a reasonable number of bytes and disconnect. If a user does end up wanting to view the full TIFF, just say "this server is probably stealing your private information and you will also go over your storage quota by loading this image". If the user is OK with that, then download the image again. 99% of the time, the image is just a company logo in someone's email signature and takes essentially zero storage space or bandwidth to retrieve at receive time. For the special cases, just warn the user about the implications of downloading the image, and go do it if they ask.
  - bartbutler 8y ago
    This is basically the plan. There are some other concerns, notably bandwidth/space and, given it's untrusted input, thinking through all the other ways it could be abused. There will certainly be a byte limit.
- Sephr 8y ago
  A Google security engineer confirmed to me that Google toyed with this idea but ultimately decided not to do it due to various partners not wishing to lose the ability to perform read receipt tracking. There are no unsolved technical reasons preventing this from being enabled in Gmail, only political reasons.
  - Jach 8y ago
    Huh, I was under the impression that Google started doing this years ago and didn't stop, and even tied it into spam analysis... Did your contact elaborate on the extent of their "toying" and any timelines? I guess I'll have to revisit some of my arguments -- a few years ago I successfully fought against adding a tracking pixel to an email template on the basis of read receipt hits not being valid hits a lot of the time (let alone never getting a hit despite being read due to images being off) due to providers like gmail pre-loading them (sometimes more than once at random times), so we should just use click-through metrics on links when the request comes with an authentication cookie.
    - Sephr 8y ago
      Google proxies and caches all external assets in emails through their own servers to hide your IP address, but they only do this on-read instead of on-delivery, which enables read receipt tracking.
brightball 8y ago
> Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email. I think those two things put together create a very, very niche use case. If I'm concerned about privacy, I don't turn on loading images by default. I'd be really curious to see the overlap in users who do.
- Oi7ie6op 8y ago
  plus those who "need" to embed visible images (e.g. marketing insisting on the company logo in the footer) could use svg data uris now, so they're not really in conflict with blocking 3rd part content.
- Sephr 8y ago
  > If I'm concerned about privacy, I don't turn on loading images by default The point is that you shouldn't have to do this, and can be afforded the same privacy while improving your user experience.
  - brightball 8y ago
    It can’t though. Whenever the image is loaded, by default or otherwise, the image itself can act as a read receipt. That’s how most email services track opens. If the server downloads the image for you, then the server has to store the image to prevent you from accessing it directly from the host. That creates cache time discussions, storage quote discussions, etc. Even if the image itself is proxied through a CDN, the time the image is accessed is still exposed.
    - disiplus 8y ago
      > That creates cache time discussions, storage quote discussions, etc. why cache time discussions, after initial download there is no need to download it again, email is not the browser, there is no expectation that the image in email will be the actual at the time of opening, the expectation is that the image is actual at the time of sending. and for storage you can use hash to not store duplicates, and probably save bandwith with optimization.
bartbutler 8y ago
Doing some sort of image proxy download in a safe and efficient way (which is not entirely trivial) is certainly part of the plan.
- deleted 8y ago
  [deleted]

ddevault 8y ago

I spoke on Mastodon recently about Protonmail - it's a scam and I cannot recommend it to anyone. They own your email, they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false. Their security is also based on trusting ProtonMail, since they could easily siphon off plaintext at the SMTP level or secretly modify their JavaScript to exfiltrate your private keys from the web browser. Genuinely secure systems do not require you to trust their operators. >PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn’t belong to anybody, there is no single central server, and you aren’t forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source. This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.

snowpanda 8y ago
>they don't support open protocols including SMTP >they could easily siphon off plaintext at the SMTP level This doesn't make any sense.
- Sir_Cmpwn 8y ago
  They don't support realying their user's outgoing mail through SMTP. They have to support server-to-server SMTP to receive incoming mail. The latter is where they encrypt incoming emails, but they could just as easily store the plaintext and you'd never know.
  - gruez 8y ago
    that limits it to the moment the email was received, which is still better than everyone else, where you can read the mail any time in the future.

marcrosoft 8y ago

Maybe the title should read "Email address verification and full PGP support". This should not be confused with real physical address verification.

Boulth 8y ago

It's nice to see their own keyserver. I wonder though if it wouldn't be more practical to support the Web Key Directory protocol [0]. WKD is both more secure than HKP (as it's always over HTTPS and authenticates user's domain), it's enabled by default in a growing number of email clients (Enigmail, GPG for Outlook, KMail) and providers (kernel.org [1], posteo.de), it's used by GPG when locating a key and the setup is incredibly easy (just put binary key in one location). (to check it out try `gpg --locate-key torvalds@kernel.org` in modern GnuPG) From my perspective it looks like a perfect match for ProtonMail for both use cases: exposing @protonmail.ch users' keys and fetching keys of contacts on other servers. [0]: https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD [1]: https://www.kernel.org/category/signatures.html https://www.kernel.org/category/signatures.html

bartbutler 8y ago
We'll probably do this soon, HKP is older and more broadly supported at the moment so it got built first.
- Boulth 8y ago
  Got it, thanks for the reply and for considering modern features!
- dane-pgp 8y ago
  That makes sense, thanks. I'd love to see support for RFC-7929 at some point too. https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929 It has the advantage of not relying on the Certificate Authority system, and not requiring a full web stack (which some email clients and servers wouldn't want to open themselves up to). DNSSEC also allows Authenticated Denial of Existence, so that unavailability of a server isn't treated as meaning the user doesn't have a key in the directory. For reference, this technology is also already supported by GnuPG and Posteo.de: https://posteo.de/en/blog/new-posteo-public-key-directory https://posteo.de/en/blog/new-posteo-public-key-directory
  - Promarged 8y ago

mirimir 8y ago

This is very good news! It's also great to have https://protonirockerxow.onion/ https://protonirockerxow.onion/ :) But I have a suggestion. If I hit https://protonmail.com/ https://protonmail.com/ via Tor, there's no warning to use the .onion address. Except for an "Onion Site" link at the bottom. And after I recently created a free account via Tor at https://protonmail.com/ https://protonmail.com/, I got that either SMS verification or a credit/debit card number was required for activation. Gak! But using https://protonirockerxow.onion/ https://protonirockerxow.onion/, there's no authentication requirement for activation. So perhaps there could be an alert when connecting to https://protonmail.com/ https://protonmail.com/ via Tor. As I recall, Bitmixer or Helix Light used to do that. Or maybe just put the .onion address near the top of the front page.

deftnerd 8y ago
There is a draft IETF standard to handle this! It uses a new "alt-svc" header that lets you specify alternative URLS to access a domain. Cloudflare is using it for their 1.1.1.1 service. If you look at the headers at https://tor.cloudflare-dns.com/ https://tor.cloudflare-dns.com/, you get alt-svc: h2="dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443"; ma=315360000; persist=1 I don't know if the Tor Browser Bundle handles this yet but its a great idea! https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-tor/ https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over... https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10 https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10
- mirimir 8y ago
  It looks like HTTP/2 (and specifically alt-svc) is explicitly disabled in Tor browser.[0] > Design Goal: SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore, all associated means that could be used for cross-domain user tracking (alt-svc headers come to mind) MUST adhere to this design principle as well. > Implementation status: SPDY and HTTP/2 are currently disabled by setting the Firefox preferences network.http.spdy.enabled, network.http.spdy.enabled.v2, network.http.spdy.enabled.v3, network.http.spdy.enabled.v3-1, network.http.spdy.enabled.http2, network.http.spdy.enabled.http2draft, network.http.altsvc.enabled, and network.http.altsvc.oe to false. Rather than redirection, I was thinking just a fork in rendering, if the user's IP is a Tor exit. 0) https://www.torproject.org/projects/torbrowser/design/ https://www.torproject.org/projects/torbrowser/design/

mikedilger 8y ago

For the other perspective, fastmail has a good write-up on why they don't offer PGP: https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/ https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/