On Tue, Jul 29, 2014 at 03:54:37PM +0000, Viktor Dukhovni wrote:
> Perhaps a better option is to change the "match" feature to a lookup
> feature which returns a value of "no | ask | require | dane", thus we'd have:
>
> smtpd_tls_ccert_policy =
> lookup_client_address static:no,
> lookup_client_helo_name static:ask,
> lookup_client_name static:require,
> lookup_client_helo_name static:dane,
>
> with "static" being just an example table type that illustrates
> the valid RHS values. With this "smtpd_tls_ccert_policy" subsumes
> and obsoletes both of "smtpd_tls_ask_ccert" and "smtpd_tls_req_ccert".
The syntactic overhead can be reduced, by making "lookup_client_helo_name"
implicit:
smtpd_tls_ccert_policy = static:dane
and we could also make "static:" implicit when the string is one
of: "no | ask | require | dane". Thus enabling a no-overhead form:
smtpd_tls_ccert_policy = ask
In addition we could also support "dane-only" (requiring TLSA RRs
from a particular set of clients), and even allow the table lookups
to return a certificate or public key fingerprint rather than "require".
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?
What are we really gaining here? Note that active attackers on the
network path can change any of the three inputs (client IP, client
name or client HELO name), so unless the client is using an MiTM
resistant sending policy, we can't prevent MiTM attacks, rather
we can only detect their absense in some cases and perhaps grant
the client greater access.
--
Viktor.
