6 ms·

I was the one who replied with that, asking him to resend without PGP, for two reasons: 1) both of our MTAs do STARTTLS. And gmail is only TLS. 2) 99% of the

I was the one who replied with that, asking him to resend without PGP, for two reasons: 1) both of our MTAs do STARTTLS. And gmail is only TLS. 2) 99% of the PGP-encrypted emails we get to security@golang.org are bogus security reports. Whereas "cleartext" security reports are only about 5-10% bogus. Getting a PGP-encrypted email to security@golang.org has basically become a reliable signal that the report is going to be bogus, so I stopped caring about spending the 5 minutes decrypting the damn thing (logging in to the key server to get the key, remembering how to use gpg). But 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. Even if I'd used PGP, I would've just replied cleartext anyway to our security@golang.org list, except all the MIME would've been garbled and unreadable. In summary, the PGP tooling sucks (especially in gmail, but really everywhere) and it's too often used by people who are more interested in using PGP than reporting valid security issues.

syscomet 10y ago
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.
- bradfitz 10y ago
  I should update our docs to say: * If you can get remote code execution in a Go program, use PGP. Otherwise do not.
  - bradfitz 10y ago
    Sent. We'll see if it's approved. https://golang.org/cl/40860 https://golang.org/cl/40860
lazyjones 10y ago
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?
- bradfitz 10y ago
  Whoops, I meant encrypted. Fixed. (Yeah, if it were just signed, that'd be fine.)
guns 10y ago
> PGP tooling sucks (especially in gmail, but really everywhere) GPG integration doesn't suck in Mutt.
- bradfitz 10y ago
  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.
  - username223 10y ago
    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.
  - unlmtd 10y ago
    I'm curious what you replaced mutt with.
- DorothySim 10y ago
  ...or Thunderbird (Enigmail) for people that like GUIs.
  - oever 10y ago
    Also fine in KMail.
scrollaway 10y ago
> 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?
- i336_ 10y ago
  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?
- bradfitz 10y ago
  I'd say it was worth it. This thread was more fun than using gpg, even if the time savings is a wash.
avar 10y ago
> 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.
- newman314 10y ago
  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-safe-than-tls-ssl https://serverfault.com/questions/523804/is-starttls-more-sa...
- syscomet 10y ago
  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
aaronmdjones 10y ago
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.

syscomet 10y ago

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.

bradfitz 10y ago
I should update our docs to say: * If you can get remote code execution in a Go program, use PGP. Otherwise do not.
- bradfitz 10y ago
  Sent. We'll see if it's approved. https://golang.org/cl/40860 https://golang.org/cl/40860

lazyjones 10y ago

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?

bradfitz 10y ago
Whoops, I meant encrypted. Fixed. (Yeah, if it were just signed, that'd be fine.)

guns 10y ago

> PGP tooling sucks (especially in gmail, but really everywhere) GPG integration doesn't suck in Mutt.

bradfitz 10y ago
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.
- username223 10y ago
  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.
- unlmtd 10y ago
  I'm curious what you replaced mutt with.
DorothySim 10y ago
...or Thunderbird (Enigmail) for people that like GUIs.
- oever 10y ago
  Also fine in KMail.

scrollaway 10y ago

> 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?

i336_ 10y ago
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?
bradfitz 10y ago
I'd say it was worth it. This thread was more fun than using gpg, even if the time savings is a wash.

avar 10y ago

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

newman314 10y ago
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-safe-than-tls-ssl https://serverfault.com/questions/523804/is-starttls-more-sa...
syscomet 10y ago
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

aaronmdjones 10y ago

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.