Quote:
Originally Posted by robn
So given all of that, I'm really curious as to what the "required TLS" from the setup you mention actually enforces. Is it just an encrypted channel, or full trust? What kind of attacks were they hoping to protect against?
|
The primary objective in almost all of these cases has generally been to ensure confidentiality of data, and you're right that the trust chain can be easily broken in a typical TLS implementation, but in the more simple implementations it was always considered "good enough" based on the relatively low probability of a compromised set of DNS records.
However, in many cases it was also a matter of using TLS to replace previous proprietary encryption gateways that some of these organizations used in the years before TLS moved into more widespread use. In some cases these were dedicated gateways, in other cases it was systems like Novell GroupWise and its "dynamic Internet link" MTA-to-MTA transfers over port 7100 (facilitated using "gwmtp" SRV records). Obviously with the evolving Internet, more and more companies have wanted to move to open standards rather than their own proprietary technologies (the same reason, IMHO, that client-side encryption technologies like PGP and even S/MIME have never gained traction).
When dealing with known communication channels (established partner/client systems), one of the strategies has been to basically create quasi-dedicated secure channels by hardcoding target mail server names. At that point, the trust chain is based not on the MX records for @somedomain.com by rather on the specific A record for the target mail server, which of course can more easily enforce a certificate match. The call here was that encryption and certificate verification was more important than mail deliverability – if MX records change, the A records on the outbound mail gateway would be updated manually.
In fact, at least two of the major banks up here that I've dealt with offer dedicated "secure mail gateways" for their business partners, different from their published MX records, that refuse all non-TLS, non-verified inbound connections. While these server names are published in DNS of course, they're not otherwise available to the public -- you basically have to know the server name to use them, and they're pretty draconian in their enforcement of certificate validation.