The thing is that STARTTLS is only one of two things that need to be fixed. Until DNSSEC is used, no smtp client/server is certain that it is delivering an email to who it is supposed to deliver it to and mitm attacks against its clients remain trivial to an ISP (I can't believe we even got there...).
Enable DNSSEC on your resolver, install Postfix, and turn DANE on in Postfix. Then when you email me @grepular.com, today, your connection to me is guaranteed to be encrypted, and guaranteed to be encrypted with a certificate matching the fingerprint that I've published in my signed DNS.
Exim will soon also be getting DANE support. Not sure if it is being worked on by other mail server teams or providers.
- DNSSEC enables and facilitates reflected DoS attacks by amplifying attackers' bandwidth;
- Using DNSSEC allows anyone to enumerate any of the zones of your subdomain, effectively turning on public DNS transfers for anyone who asks (see the paper for attacks against NSEC and NSEC3);
- DNSSEC enables and facilitates reflected DoS attacks by amplifying attackers' bandwidth;
That's a problem today, without DNSSEC, and requires fixing regardless, whether or not DNSSEC becomes wide-spread.
- Using DNSSEC allows anyone to enumerate any of the zones of your subdomain, effectively turning on public DNS transfers for anyone who asks (see the paper for attacks against NSEC and NSEC3);
I thought NSEC3 fixed that, but I wouldn't be surprised if there were attacks against it. I don't think that's an insurmountable problem.
Chicken and egg. shrug There's no reason an OS can't come with such a resolver built in. Personally I take the 60 seconds or so required to do an "apt-get install unbound" to get this functionality whenever I build a system.
https://github.com/EFForg/starttls-everywhere
I'm not sure one could say that this makes STARTTLS non-broken, but it will help mitigate the MITM risk.