So DANE is only useful if all hops in the path support and use DANE and only useful then.
Just one hop not using DANE and it’s useless.
Generally speaking, there is only one hop that is SMTP to SMTP where certificate authorities are ignored.
Client connects to Port 587 to send. Client involved. Certificate can be be validated, asking human what to do if there is a problem.
The SMTP server then looks up what SMTP server(s) are associated with the recipient domain, picks one, connects, and sends. That’s the hop where DANE is mandatory for e-mail to be secure.
The recipient SMTP then either puts it in a mailbox or sends it to another SMTP to put it in a mailbox, but that is all within the recipient domain where they could even hardcode the public keys to use for any additional hops because they admin it all.
There really is only one hop to worry about, and yes, that hop requires DANE to be secure. Otherwise that hop is susceptible to both DNS cache poison (solved by DNSSEC) and/or fraudulent cert (solved by DANE).
Even with DANE, because e-mail is only encrypted hop to hop, if you really need it to be secure then you have to use something like GNUPG os S/MIME - and guess what, those too now can be secured by DANE so you don’t have to mess with the key distribution part manually.
DNSSEC adoption is slow, that is true. That is the real problem.
Security and Privacy start with DNS.
Another thing I would like to say -
The goal of getting more companies to run their own mail servers is a very very very very good one I absolutely applaud.
One of things I fear is that this centralized list will reduce the motivation companies have to actually implement DNSSEC. And it’s not actually hard to implement DNSSEC. It sounds scary because you mess up and you brick your site, like HBO did, but those kind of mistakes are actually not hard to avoid.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.