HTTPS Everywhere? This Email Service Gives You DANE, Too • Hacker News Board

Re: HTTPS Everywhere? This Email Service Gives You DANE, Too

#11

Post by alex_duf » Tue, Oct 21, 2014, 3:01 AM UTC

mike-cardwell wrote: post #7

alex_duf wrote: post #3

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

Fair point.

Re: HTTPS Everywhere? This Email Service Gives You DANE, Too

#12

Post by virtue3 » Tue, Oct 21, 2014, 3:30 AM UTC

Buge wrote: post #10

rostigerpudel wrote: post #5

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 dow…

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

Re: HTTPS Everywhere? This Email Service Gives You DANE, Too

#13

Post by jbert » Tue, Oct 21, 2014, 8:50 AM UTC

mike-cardwell wrote: post #8

jbert wrote: post #4

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.

Re: HTTPS Everywhere? This Email Service Gives You DANE, Too

#14

Post by mike-cardwell » Tue, Oct 21, 2014, 11:45 AM UTC

jbert wrote: post #13

mike-cardwell wrote: post #8

Earlier quoted context omitted.

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 sh…

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.

Re: HTTPS Everywhere? This Email Service Gives You DANE, Too

#15

Post by jbert » Tue, Oct 21, 2014, 3:23 PM UTC

mike-cardwell wrote: post #14

jbert wrote: post #13

Earlier quoted context omitted.

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 sh…

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 connectio…

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