ietf-dane at dukhovni.org
Thu Jan 15 18:11:03 CET 2015
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
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
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.
More information about the dane-users