On Thu, Jan 15, 2015 at 05:39:09PM +0100, Frank fiene wrote:
It was not designed for client authentication. But what is the problem for Mailserver to Mailserver authentication in both directions?
All well administrated mail system have reverse DNS configured, if that would be DNSSEC secured, perfect!
It can't be DNSSEC secured. The MiTM attacker can change the apparent IP address of an email stream (source NAT it). Even IPsec won't help, it'll just establish that the source NAT flow is securely coming from the MiTM's IP address.
So reverse DNS, then TLSA/DNSSEC plus Certificate validation and everything would be fine for both sides!
Except that this is useless. It proves nothing about the true origin of the sending entity, nor are PTR records the right name for a client in many cases, as that name space is controlled by the ISP, not the customer.
For client DANE to work with SMTP, it would have to be based on the EHLO name, or some similar name provided in-band via a new SMTP command.
Clients would be free to not send such a name, so these names would not be usable to restrict access, they would only be useful to whitelist.
The apparent symmetry between client and server in "mutual authentication" is mostly an illusion. Authentication of the server protects the channel, while authentication of the client protects the requested resource, and is only useful when the resource supports restricted access, or the protocol support role reversal with the server becoming a client and wanting to know whether the peer is authentic in that new context.
You're getting carried away with an over-simplified security model.