301306Re: Individual smtpd_tls_ask_ccert?
- Jul 29, 2014Am 29.07.2014 um 19:06 schrieb Viktor Dukhovni:
> The syntactic overhead can be reduced, by making "lookup_client_helo_name"First we should extend DNS using another MX-like entry, to be able to
> 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.
define authoritative MTA client nodes for a specific domain, so we have
something to stick on. Then we can build the same ("backfiring")
security checks, like we have on server connections today.
- << Previous post in topic Next post in topic >>