
Address Verification and Full PGP Support - johnnycarcin
https://protonmail.com/blog/address-verification-pgp-support/
======
ddevault
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.

~~~
MrBingley
> They excuse this nonsense by saying that it's necessary for encryption,
> which is blatantly false.

I don't see how this is false. Protonmail encrypts all user emails on the
server, which can only be unlocked by the user's password. SMTP and IMAP would
require transmitting the password to the server for decryption, which makes it
prey to interception a la HushMail [0]. This is why they have the bridge,
which runs its own IMAP server on the client and performs all authentication
and decryption locally. Of course, the bridge isn't open source yet, so we
can't be sure it isn't sniffing your password anyway, but that is orthogonal
to the issue of supporting SMTP.

[0] [https://www.wired.com/2007/11/encrypted-e-
mai/](https://www.wired.com/2007/11/encrypted-e-mai/)

~~~
Sir_Cmpwn
No, they could just transmit PGP encrypted emails down IMAP and the user could
decrypt them with any number of popular PGP implementations. Your IMAP/SMTP
password doesn't necessarily have to be the same as your PGP key password, nor
should you even need to give Protonmail your PGP private key (password
protected or not), nor does IMAP/SMTP even have to be authenticated with a
password (GMail notably pioneered an OAuth-based extension to both).

~~~
bartbutler
This is completely ignoring key management as a barrier to using encryption,
not to mention manually syncing local keystore with the server, not being able
to provision keys across devices, etc. In other words, why PGP and email
encryption in general has largely been a failure over multiple decades. It's
too complex and too difficult.

~~~
Sir_Cmpwn
None of these difficulties prevent you from making the access available. It
has no bearing on users who already choose not to use IMAP. This is a pretty
bad excuse.

~~~
bartbutler
Only if you completely discount the related costs of building and maintaining
such an additional API as well as the customer service impact of basically
allowing users to screw up their own key management.

~~~
Sir_Cmpwn
Even if I concede this to you (and I don't), you've already written an
IMAP/SMTP bridge that solves these problems. Open source it and make it
available to free users and the problem disappears (well, is reduced. Most
non-technical users don't know how to run a daemon after all, and making them
put it on their own infrastructure is lame as hell).

~~~
bartbutler
Because running PGP software and handling key management locally is way easier
than double-clicking on an installer? I don't concede that for a second.
Remember that the alternative you want is ciphertext directly via IMAP, which
is not at all user-friendly, which is exactly why we didn't do it.

As for the bridge, that is exactly what we'd like to do, as I've said before.

And customer support time and developer time devoted to this would cost money
and represents an opportunity cost as well and that's a fact, not a point to
be conceded.

~~~
Sir_Cmpwn
I said even if _I_ concede, I didn't expect you to.

And like I've said before, what you'd like to do and what you are doing are
different. Nothing stops you from open sourcing it today. Put in comments that
the APIs you use are not officially supported if you must. Open source it! It
should have been open source a year ago! Open source it!

~~~
auslander
And you give me all your money. Give me All Your Money!

Some people are just like that :)

Great product, Proton team, thanks.

------
mirimir
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
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...](https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-tor/)
[https://tools.ietf.org/html/draft-ietf-httpbis-alt-
svc-10](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-10)

~~~
mirimir
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/)

------
Boulth
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
We'll probably do this soon, HKP is older and more broadly supported at the
moment so it got built first.

~~~
dane-pgp
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
> It has the advantage of not relying on the Certificate Authority system

I wouldn't say it's an advantage, while CA system has many flaws at least it's
monitored somehow (for example via Certificate Transparency) while putting
keys in DNS would require the app to validate records (does GnuPG do that?),
not to mention the queries are not encrypted (so are visible to any hop) and
could be transparently replaced by your government or TLD operator. Many DNS
providers do not allow adding "exotic" records.

For further info see e.g.: [https://sockpuppet.org/blog/2016/10/27/14-dns-
nerds-dont-con...](https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-
control-the-internet/)

> and not requiring a full web stack (which some email clients and servers
> wouldn't want to open themselves up to).

Email clients and servers that do PGP usually have "full web stack" already to
connect to keyservers.

Additionally while DANE or PKA lookups can be enabled in GnuPG only WKD is
enabled by default ("auto-key-locate" is "local,wkd").

Nice nick by the way :)

------
Sephr
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
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.

~~~
jrockway
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
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.

------
marcrosoft
Maybe the title should read "Email address verification and full PGP support".

This should not be confused with real physical address verification.

------
mikedilger
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/)

------
kradle
relevant: [https://blog.cryptographyengineering.com/2018/05/17/was-
the-...](https://blog.cryptographyengineering.com/2018/05/17/was-the-efail-
disclosure-horribly-screwed-up/)

