HTTPS Everywhere? This Email Service Gives You DANE, Too

Re:HTTPS Everywhere? This Email Service Gives You DANE, Too by jbert on Tuesday October 21, 2014 @04:50AM (#8486486)

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.

[ Parent | on HN ]

Re:HTTPS Everywhere? This Email Service Gives You DANE, Too by mike-cardwell on Tuesday October 21, 2014 @07:45AM (#8486852)

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.

[ Parent | on HN ]

Re:HTTPS Everywhere? This Email Service Gives You DANE, Too by jbert on Tuesday October 21, 2014 @11:23AM (#8487789)

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

[ Parent | on HN ]