> I recognized him as a knowledgeable person from the Internet, and I knew (1), so I just asked him to send without PGP to save me 5 minutes.

I understand where you're coming from but this bit of logic I don't get. Especially if you recognized him, then clearly it's worth spending the five minutes.

The five minutes you personally save, someone else has to pay them. The person who originally sent you the email now has to read the response, process it, send you another non-encrypted email and/or enter into a meta-debate with you. They end up mentioning it on their blog and now we're all having this meta-meta-chat about it on hacker news, wasting several man-hours on it.

Was it worth it?

I'd say it was worth it. This thread was more fun than using gpg, even if the time savings is a wash.

Negatively-anticipatory subjective analysis of the effort and difficulty of a task that needs to be done and which the brain has not "task-switched" into actually doing yet. (What's this canonically described as?)

Something we all do, and which I'm personally very guilty of.

In this case it was exacerbated by "99% of PGP-encrypted security reports being bogus" (to paraphrase).

I can clearly see both sides of this coin though (security!), and I'm not at all discounting what you're saying.

It's both ridiculous and horrendous that PGP remains an operational holy grail after how many decades?

STARTTLS is not required to be used (even if the peer advertises it), can be stripped from the advertisement by an MITM (and the relevant RFCs say you shouldn't configure your MTA to require STARTTLS for every peer), and the standards even say that the session should continue even if the certificate verification fails (absent any site-specific configuration).

This is strictly worse than the problem you're writing about (lack of SSH host key verification) because at least with SSH you know the link is going to be encrypted (perhaps only between you and an MITM, but I digress...), but with ESMTP you can't assume even that. For example, it is perfectly acceptable for Google to one day decide not to negotiate TLS with ESMTP MTAs it's delivering mail to. You could check the message Received: headers on all the E-mail you receive to see if it was used, but by that time it's too late.

Those figures are both good and depressing to know, thanks.

I figured the PGP usability problems were severe enough that I did not call you out by name in the post. This aspect was merely a darkly amusing aside leading into the main point of how the Golang devs handled this so well.

You didn't know the content of the report, so the irony is only clear in retrospect: the whole point of the report was about vulnerability to MitM attack and email MX->MX delivery is highly susceptible to that without some kind of trust anchoring in place, whether DANE or MTA-STS, neither or which is in place for the golang.org domain.

So the fact that TLS is _advertised_ by the gmail servers, which handle golang.org mail, doesn't mean that the advertisement reaches the sending mail-server.

I've since configured my mail-servers to always require verified TLS for outbound mail to the golang.org domain, as a manual override.

I should update our docs to say:

* If you can get remote code execution in a Go program, use PGP. Otherwise do not.

Sent. We'll see if it's approved. https://golang.org/cl/40860

    > 1) both of our MTAs do STARTTLS. And gmail is only TLS.

What you're implying here, i.e. that the communication is encrypted anyway, isn't how E-Mail works at all.

Even if the GMail MXs are configured to only accept E-Mails over TLS, the user's sensitive E-Mail may, depending on his settings, traverse multiple servers with less secure settings before a connection is ever initiated with the GMail MXs.

If someone's E-Mail is going to be MITM'd it's far more likely to happen between the Internet café he's sitting in and his ISP's badly configured SMTP server than between his ISP's SMTP server and GMail's TLS-using MTA.

GMail using TLS will do nothing to protect against the message being MITM'd, whereas GPG would, because it's end-to-end encryption, unlike TLS settings for individual MTAs in a possibly long chain of mixed or no encryption before a message reaches you.

Do we have any confirmation that Google has mandatory TLS?

IIRC, STARTTLS may not be mandatory and be just purely opportunistic. So relying on STARTTLS only is not a good idea.

https://serverfault.com/questions/523804/is-starttls-more-sa...

Brad knows me slightly better than that and there was a bit more factoring into his decision. As I'm one of the maintainers and security/release people for Exim, a major MTA, I'd hope that the SMTP server on my personal domain is not too badly configured. :-D

> PGP tooling sucks (especially in gmail, but really everywhere)

GPG integration doesn't suck in Mutt.

I used to use Mutt, and I appreciate that some people still love it, but I don't intend to go back to it just for PGP support.

If PGP (or something like it) is going to catch on, it has to do so for everybody's MUAs, not just nerd ones.

You're apparently someone with at least a bit of influence at GOOG, which makes Gmail. If you cared about PGP, maybe you could use a bit of your power.

...or Thunderbird (Enigmail) for people that like GUIs.

Also fine in KMail.

I'm confused about the use of "PGP-signed" vs. "encrypted" here. Why do you need to decrypt PGP-signed emails? I guess they were signed AND encrypted and the problem was the encryption, not the signature. So presumably just PGP-signed cleartext should cause no problem for security reports. Or is that problematic too for some gmail-related reason?

Whoops, I meant encrypted. Fixed.

(Yeah, if it were just signed, that'd be fine.)