Am 29.07.2014 um 19:06 schrieb Viktor Dukhovni: > 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.
First we should extend DNS using another MX-like entry, to be able to
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.
Wishful thinking...
;-P
BlueStar88
signature.asc
Description: OpenPGP digital signature
