* Viktor Dukhovni <postfix-users@postfix.org>: > 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?
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 This could all take place on a publicly referenced MX. Assuming both parties agreed to enforce TLS it would be RFC compliant. > 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. > 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. Correct me if I am wrong: Client-side DANE and/or ccert fingerprint matching would be apt to prevent MiTM attacks. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
