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.