4 ms·
The proper long term solution to this problem is DANE [2], but since migrating everyone to DNSSEC will take a long time, Google and a few others in the email ec
by ttul 4y ago
The proper long term solution to this problem is DANE [2], but since migrating everyone to DNSSEC will take a long time, Google and a few others in the email ecosystem created MTA-STS, which is far better than nothing [1].
All this being said, another idea (not standardized yet as far as I know) would be to publish a new DNS record, MXS (for example), that would imply the use of the SSL email port 465. I think it would be a worthy standardization effort to go in this direction and finally banish STARTTLS.
[1] https://dmarcian.com/mta-sts/ https://dmarcian.com/mta-sts/
[2] https://www.rfc-editor.org/rfc/rfc7671.html https://www.rfc-editor.org/rfc/rfc7671.html
- tsimionescu 4y agoHow would any of these fix vulnerabilities in the handling of STARTTLS? And why is any of them required in place of just using TLS as part of the initial connection, HTTPS style?
- ttul 4y agoYou can’t fix STARTTLS unless receivers stop advertising it. That will take until the end of time. Meanwhile, DANE can assure that domains can assert their SSL certificate in the DNS securely. And MTA-STS can allow DNS to do so, just without the assurance of DNSSEC, which implies that sophisticated man-in-the-middle attacks can still occur, if DNS can be intercepted and modified.
- tptacek 4y agoIt's probably worth noting that the attacks a state-level actor would use to subvert MTA-STS are more sophisticated than the attacks those same actors would use to subvert DNSSEC, which is a global tree PKI whose roots are de jure controlled by state actors.