Re: opportunistic email encryption by the MTA (not MUA)
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.
Re: opportunistic email encryption by the MTA (not MUA)
fyi, i was contacted by a clue holder from protonmail. my guess was correct. they pointed me to the wkd section of https://protonmail.com/blog/security-updates-2019/ as i responded to them: 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. randy
Re: tiny gorillas, was opportunistic email encryption by the MTA (not MUA)
In article 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. R's, John
Re: opportunistic email encryption by the MTA (not MUA)
On Fri, 2021-01-15 at 10:26 -0500, Bryan Fields wrote: > > It's still stored unencrypted on the server, and the admin can see > all. This is true. I was just referring to transit leakage. > If > you want it secure, you have to run gpg and encrypt the body. Again, true. Cheers, b. signature.asc Description: This is a digitally signed message part
Re: opportunistic email encryption by the MTA (not MUA)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/15/21 7:22 AM, Brian J. Murrell wrote: > 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. It's still stored unencrypted on the server, and the admin can see all. If you want it secure, you have to run gpg and encrypt the body. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmABtBgACgkQYTmgYVLG kUBjBQ/+McM45Kab7YdmzeqIeoZcR8Hy2JIZo4cWj/bQdKxzjIhZmvxacK8FJWwJ 06Vd3QynYLO2pRi/7GAJ6vLhNFd6Q2Nhh5ABADpwj6h0hWz4ULQ7hm1Wn8vdIofN lOCef4xHYTIXGVN//QgWaUqdogwup3QdBbbWQsAh3rNbW9jYq4UrIGaEpVXJ+tsp h55eoDcmX8P/SGkL4B0WBiv3IzMGfRMlcPHCRU7xCrQLCW34KEOcog2QyBv6ZSAk yT3fsy8uiNg5S464YqXGEQT9/LuWDl1yMSJ4nhVDDAp+mbAcMCbpl7Hb3IWzUAJj 0v8D5yoUhYBeamCfTj19DSCnMONUAMlPlEiIlfQXvdrQaRBL2QJjwooGU5lDG+Zm u/8M+M8bUNjSF2V7Y7JwszBkx1lkGuVMdXKjhnMM2/M+56AD9BJAsq2M2nEzE8Xz CoAglEhUoL3vNN7HiLBrN8heGtF2aOXSI2cU9qzgL44d28nz+OyxWyiv3GWTYETA mWCIz8RuYLwOh+EzAsx9AzsPhAYPUJnTMwdZb65QYsdXpDKtw3fvKrASHcJtn4I4 lxhCD66wOsJY/mypaDB973L7eyvUTVL/2E1qkXYbGVw/X5wxv6ohWr5zR7IbqLVY FBTMsVnV4VcJsSLtCYku4BNWl4knYN7f8tQcVcMbpiToEYJXP3Q= =Mo06 -END PGP SIGNATURE-
Re: opportunistic email encryption by the MTA (not MUA)
On Fri, 2021-01-15 at 03:33 -0800, Randy Bush wrote: > 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]. 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. Use of it at the MTA level is interesting. Cheers, b. signature.asc Description: This is a digitally signed message part
opportunistic email encryption by the MTA (not MUA)
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 /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:08:44:41 +] "HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:08:44:42 +] "GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:10:49:44 +] "HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:10:49:45 +] "GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:15:02:49 +] "HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" /var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:15:02:49 +] "GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11" 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. anyone with protonmail clue or contact(s)? randy [0] - https://git.rg.net/randy/randy/src/master/pgp-WKD.md
