Hi --
Very recently I started to implement and investigate DNSSEC and DANE at a test server (separate FreeBSD jail with postfix). I am using OpenDNSSEC for key rollover management and KSKs and ZSKs with 2048-bits and algorithm 8. While learning (Open)DNSSEC I made a mistake (misuse of OpenDNSSEC functionality) and screwed my chain of trust, thus making my test server "unknown" to DNS. Well, I learned how to deal with that, but that experience made me think about a "fallback" setup for hosts that somehow managed to screw their chain of trust as well.
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, and implemented:
postconf -n | grep ^smtp_: smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_generic_maps = pcre:/usr/local/etc/postfix/smtp_generic_maps smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 smtp_tls_note_starttls_offer = yes smtp_tls_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
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:
Do I miss something that might break my approach? Or, is there a more elegant way to implement a fallback oTLS?
Thanks and regards, Michael
[1] only a handful users, but outgoing mail should not fail, never :-)
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).
On 07.02.2015, at 23:58, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
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.
Sorry for my broken English, fallback is wrong, now I know. What I actually meant is: explicitly allow delivery for "broken" hosts on purpose, no automatic fallback. Sorry.
/usr/local/etc/postfix/transport_maps /^example.com/ opportunistic-tls
Why use regexps for this (badly at that)? Use a non-regexp table,
Ok, thanks for that hint.
or learn how to write 100% correct regular expressions (your's is only 2/3 of the way there).
Yeah, I see, but honestly, normally I do add a trailing '$' :-)
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).
Well, I see. I will stick with a pure opportunistic SANE for the time being.
Thank you very much and with kine regards, Michael
Michael Grimm wrote:
What I actually meant is: explicitly allow delivery for "broken" hosts on purpose, no automatic fallback.
This let's you easily specify any TLS policy per recipient site:
http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps
Ciao, Michael.
On 09.02.2015, at 14:19, Michael Ströder michael@stroeder.com wrote:
Michael Grimm wrote:
What I actually meant is: explicitly allow delivery for "broken" hosts on purpose, no automatic fallback.
This let's you easily specify any TLS policy per recipient site: http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps
Sigh. A default smtp_tls_security_level = dane and exceptions per host in smtp_tls_policy_maps are surely more elegant than my approach using a different transport [1]
Thanks and regards, Michael
[1] which I somehow misunderstood in http://www.postfix.org/TLS_README.html#client_tls_dane
participants (3)
-
Michael Grimm -
Michael Ströder -
Viktor Dukhovni