HTTPS Everywhere? This Email Service Gives You DANE, Too
blog.tutanota.de> SSL makes man-in-the-middle attacks all too easy. Every owner of root certificates that is certificate authorities, secret services and big Internet providers can intervene between user and server to intercept confidential information or even manipulate it.
This problem doesn't go away with DNS (in fact without DNS-Sec it's as good as a self-signed cert) and with DNSSec, state actors/root delegates can still act maliciously.
Granted, I still think it's a better option than the current CA system, it just doesn't magically make certain kind of attacks go away.
Doesn't this just swap the existing set of trusted CAs (used to bootstrap TLS trust) for a new set of trusted DNS root operators (used to bootstrap DNSSEC trust)?
Surely if you're worried about state actors, this is no help?
Today, SMTP can be trivially MITM'd by anyone on a network, not just state actors, even if TLS is supported. All you have to do is remove "STARTTLS" from the servers EHLO response and then everything is in the clear.
Forcing a MITM to compromise DNSSEC before they can read the cleartext is a worthwhile barrier to add IMO.
Thanks for that. Do you have an understanding of what would happen if SMTP servers switched to demanding TLS (i.e. bouncing the message if next hop doesn't offer STARTTLS?) with validated certs?
It would hurt mail reachability, but are there any useful numbers as to how badly?
Additionally, it seems as though a solution analogous to HSTS might be better than involving DNSSEC. An SMTP server could advertise that it should be connected to only over TLS - information that could be cached by the sending system.
There is still a MITM problem on 1st connection, but that's an issue for many systems and avoids trusting DNSSEC.
I'm not sure what proportion of servers use TLS. I imagine a lot of mail would go missing if you started to require it though. IIRC, Google started publishing numbers somewhere.
The good thing about involving DNSSEC+DANE is that, even the first time an SMTP server connects to another, it knows that it must use TLS and must expect a particular certificate. With HSTS you don't get that protection on the first connection.
I guess I would prefer that SMTP "skip over" the CA/DNSSEC model and go straight to something like HSTS+TACK to add the expectation of validity to the expected certs, rather than place trust in the DNSSEC roots.
I guess DANE (with or without DNSSEC) could also be used to cover the first connection, but I guess I'd prefer a world where the previous connection was used as the primary point of trust (the HSTS+TACK approach) rather than the "trusted root" (DNSSEC or CA).
Some reasons why I do not like tutanota:
* They say the combination of AES-128 and 2k RSA keys is secure
* The private key is stored on their servers (password needs to be set, but if security hinges on the private key password...)
* The website contains FUD (e.g. the FAQ [1])
* They have been sending UBE with loads of FUD to promote their services
[1] https://tutanota.de/#!faq (the language switch is all the way down at the bottom)
Yep. Note also that DANE (as they mention) currently depends on the full-blown DNSSEC stack to be useful. However, the full-blown DNSSEC stack suffers from many technical and design-related problems:
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
http://ianix.com/pub/dnssec-outages.html
Disclaimer: I work on DNSChain, a blockchain-based alternative to DNSSEC & X.509. Note that DNSChain does support blockchain-authenticated DANE TLSA records. In the future, DNSSEC's SIG record may be used to provide MITM-proof verification of the validity of that TLSA record for DNS-based apps.
Are AES-128 and 2k RSA keys not secure?
I know 1k RSA isn't secure, but I thought 2k was.
"Assuming the hypothetical NSA breakthroughs don't totally break public-cryptography -- and that's a very reasonable assumption -- it's pretty easy to stay a few steps ahead of the NSA by using ever-longer keys. We're already trying to phase out 1024-bit RSA keys in favor of 2048-bit keys. Perhaps we need to jump even further ahead and consider 3072-bit keys. And maybe we should be even more paranoid about elliptic curves and use key lengths above 500 bits."
from Schneier's post: https://www.schneier.com/blog/archives/2013/09/the_nsas_cryp...
There is some speculation that the NSA could potentially have quantum computers in which case RSA(and basically everything) is just fucked. Hopefully that's not the case (but hey, what your shadow budget is more than the rest of the world spends on crytopgrahy research combined then who knows, right?)
I also have support for DANE on grepular.com, for web and also MX. I've only been doing it for MX for a couple of weeks though. Postfix now supports it.
edit: This is just a hobby domain though.
Soo, instead of having DNS + CA to hack now we just need to hack the DNS ?
That seems like a single point of failure to me.
"DNS + CA" ? Don't you just mean "CA". And when you say "CA", don't you mean, "1 out of hundreds of CAs" ?
Besides there are no CA's for SMTP anyway. Encryption is entirely opportunistic, and self-signed certs are just as trusted as ones signed by one of the CA's that people use for web traffic.
The difference with DANE+SMTP is, all of a sudden a sending server will know that it must use TLS or not send the message. And the cert it receives must match the one published in the DNS. Not just one that is signed by one of any hundreds of CAs.
Fair point.