email from a friend who uses protonmail as their MTA suddenly started to
be opportunistically encrypted with pgp; i.e. the sender's MUA did
nothing to cause the encryption. i believe this started when i provided
my pgp public key over WKD [0].
i have a guess. i suspect that protonmail opportunistically tests for a
WKD for the recipient and, if found, uses it. i do see protonmail
queries to my WKD service
my interest is whether WKD publication is triggering opportunistic
encryption; if anything else might be using it opportunistically, and if
this can actually scale.
i really do not want to discuss if pgp encryption is a good thing, if
opportunistic encryption is the spawn of the frog goddess, or if there
are viable alternatives to emacs.
Interesting. When I read the subject though, I have to admit that I
was hoping your e-mail was going to be about REQUIRETLS/RFC8689.
It's a real pity that there appears to be no real-world
use/implementation of RFC8689.
I think in practice the old adage that "e-mail is insecure" is becoming
untrue, by a significant amount, I suspect, due to the prevalence of
STARTTLS.
The problem with STARTTLS of course is that it is opportunistic only
and with no way for the sender to indicate that a message MUST use TLS
or not be delivered at all.
I routinely send things by e-mail that, while they are not the
combination to the big safe at Fort Knox, they are not something I
would staple to utility poles.
When doing such I will typically look up the MXes for the recipient and
test their SMTP port for STARTTLS to see if the mail will at least ride
the wires with TLS.
It would be so much easier to have a checkbox in my MUA to do this
though.
All of that said, thanks for the pointer to WKD. I didn't know about
that.
In article <a1f45fdbf44300cc0e6058b3e52568f3d0a61091.camel@interlinx.bc.ca> you write:
It's a real pity that there appears to be no real-world
use/implementation of RFC8689.
I implemented RFC8689 as soon as Jim proposed it. My MTA recognizes
the REQUIRETLS option and then ignores it.
A lot of people who really should know better imagine that they can
announce something on the Internet and other people will have to do
what they say. It has never been true, and it is still not true. We've
seen this before with SPF -all where people are surprised that other
mail systems accept mail anyway.
Opportunistic TLS is fine, as is MTA-STS which says "if it doesn't
offer STARTTLS it's not me". Neither of those purport to tell other
systems what to do.
i am definitely wondering how well it scales. it adds query
burden, often toward a server different than the smtp target.
e.g. the wkd server could have sucky performance.
While I agree pretty much entirely with everything you've expressed,
there is another force in the world quietly chugging away to make
sure that email privacy remains largely hypothetical...and that is:
cloud computing.
A lot of people have outsourced their mail service to cloud operations,
so even if the mail servers on both ends do everything "right", which
(to your point) might include a refusal to transmit messages unless an
over-the-wire encryption method is agreed on, messages thus sent are
available in plaintext on both sides of the transmission and thus can
be inspected/collected/etc. at will by the operators of the cloud [1].
Or by anyone who's penetrated the cloud.
Note that while use of PGP/similar to encrypt the message itself helps
with this, that doesn't stop traffic analysis on either side of the
transmission.
---rsk
[1] Which includes the people working there and working for them,
as well as the people working there and not working for them.
