Opportunistic DANE / TLS per host

[Viktor Dukhovni]

On Sat, Feb 07, 2015 at 10:18:17PM +0100, Michael Grimm wrote:

> http://www.postfix.org/TLS_README.html#client_tls_dane shows me an opt-in
> approach for opportunistic DANE (if I am not completely misunderstanding).
> 
> What I want to implement is an opportunistic DANE approach with fallback
> to opportunistic TLS for "DANE broken" hosts,

I'm holding off on implementing any automated fallback with DANE,
because I want broken sites to fix their breakage, rather than make
all senders accommodate broken sites.  If we automatically fall
back to unauthenticated TLS (with log warnings, ...), broken sites
become entrenched, and we never get DANE implemented with authentication
enforced.

> 	smtp_dns_support_level = dnssec
> 	smtp_tls_security_level = dane
> 	smtp_tls_loglevel = 1
> 	smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
> 
> plus "broken" hosts:
> 	transport_maps = pcre:/usr/local/etc/postfix/transport_maps
> 
> /usr/local/etc/postfix/transport_maps
> 	/^example\.com/     opportunistic-tls

Why use regexps for this (badly at that)?  Use a non-regexp table,
or learn how to write 100% correct regular expressions (your's is
only 2/3 of the way there).

> master.cf:
> 	opportunistic-tls       unix  -       -       n       -       -       smtp
> 	      -o syslog_name=postfix/otls
> 	      -o smtp_dns_support_level=enabled
> 	      -o smtp_tls_security_level=may
> 
> This is working on my test server, but before implementing that scheme on
> my productive server[1], I'd like to ask you experts out there:

This won't help you if the sites DNS is returning "bogus" MX and
A/AAAA replies, because the local validating nameserver returns
SERVFAIL no matter what "smtp_dns_support_level" you choose.

Postfix (through limitations in libresolv) cannot set the the "CD"
bit in DNS requests, and so never sees DNS results that fail
validation.

This only helps you when the problem is with TLSA records that
don't match the server's chain.  Such configurations are for
emergencies only.

> Do I miss something that might break my approach? Or, is there
> a more elegant way to implement a fallback oTLS?

To bypass DNSSEC problems you need to forward mail to another
machine whose local DNS resolver is non-validating.  That machine
can deliver mail to sites with known broken DNSSEC (which you
somehow decide is not an MiTM attack).

-- 
	Viktor.