Opportunistic DANE / TLS per host
trashcan at odo.in-berlin.de
Sun Feb 8 00:29:52 CET 2015
> On 07.02.2015, at 23:58, Viktor Dukhovni <ietf-dane at 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.
>> /^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 '$' :-)
>> 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, 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
> 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,
More information about the dane-users