On Tue, Jul 29, 2014 at 11:59:41PM +0200, Patrick Ben Koetter wrote:
> > Which brings us back to the key question, what is the real motivation
> > for this? Preventing HELO forgery? Making TLS access control easier
> > to use (with "dane-only", one might be able to use check_helo_access
> > safely, because certain HELO names would be authenticated)? Some sort
> > of audit-trail that the client connection was not MiTMed?
>
> The use case goes like this:
>
> Company A and B agree to use TLS in order to protect communication. While it
> is simple for A to create a policy that enforces TLS when they send to B,
> there's no easy way for B to enforce TLS on their (inbound) side.
>
> B may create a SMTP TLS-only listener on a dedicated port/ip and tell A to use
> that. Alternatively, if the feature we are discussin at the moment, was in
> place, they may as well create a policy that
>
> a) requires TLS if A's IP/hostname is used by the client
> b) requests the client to send its ccert
> c) verifies the clients ccert fingerprint matches one put down in a map
What is the purpose of such enforcement? Thwarting MiTM attacks,
or an audit trail of the cases when the "real A" sends unintercepted
messages?
> > What are we really gaining here? Note that active attackers on the
>
> The gain is mutual authentication. At the moment the SMTP server has no means
> to enforce TLS selectively on its default ip/port.
Mutual authentication is surely not an end in itself. What purpose
does it serve?
> Correct me if I am wrong: Client-side DANE and/or ccert fingerprint matching
> would be apt to prevent MiTM attacks.
Perhaps by now you'll believe me that it can't. Rather it can
prevent granting access rights to an authenticated party over an
insecure channel. With SASL, if the client fails to authenticate
the server, the credentials are not channel-bound to the TLS crypto,
and there could be an MiTM manipulating the authenticated session.
With client certs, whoever authenticated with the cert is also the
party with the channel encryption keys. Thus SMTP client certs
only prevent MiTM of specially authorized clients when they are
accessing a suitably restricted service.
Do you still want enhanced client certificate support? It is it
too little gain for too much effort? (I'll probably build it
anyway, so please speak freely).
--
Viktor.
