danmarg

But the private key is (of course) never sent to GitHub, so it's hard for me to imagine what kind of vuln this would help with. I can think of a few, but they're odd:

1. Some sort of remote memory leak that leaks the current private key, I guess.

2. Some sort of relay attack where you can impersonate the legit host.

In both of these cases, it seems like at a minimum you would need to, on the client, set up an ssh config that limits each identity to each host so as to prevent the client from trying each key in sequence (and thus potentially exposing it). That's a huge hassle!

So I guess tl;dr: I can think of a few cases where this might be useful, but if you're always SSH'ing from the same laptop, this step can probably be pretty far down your list of things to do.

Is the mailer-daemon message from @googlemail.com or from recipient domains?

But I think the authentication problem is in fact the hard problem. Assuming we got rid of STARTTLS (the actual verb) and just always did TLS (say, on some other port), how do you propose to solve it?

If you required TLS on all SMTP, you would in fact end up having to fail a large number of messages.

Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it may not be trusted for the domain.[1]

So I think unfortunately we're not anywhere near a world where we could actually just drop email on the floor if TLS-with-a-valid-cert isn't present ("valid" not being clearly defined here, of course). I do think we're slowly moving in that direction[2].

It's certainly true that retrofitting security makes the whole thing more complicated, of course. That's a strong argument for ensuring that any retrofitting we do is itself forward-compatible with what we want to do in 30 years. Or for inventing time machines.

1. http://static.googleusercontent.com/media/research.google.co... 2. e.g. http://arstechnica.com/information-technology/2016/02/gmail-...

I don't think the use of a single port is really at the heart of the problem. Even if SMTP with TLS ran over port 26 (say), you wouldn't know if a timeout on port 26 meant the server wasn't listening on port 26 or a MITM had just chosen to drop your packets.

Discovering if someone supports Protocol++ if the fallback to Protocol is insecure is a hard problem.