[pfx] Re: Behavior of smtp_tls_security_level = dane
On Sun, Mar 17, 2024 at 03:19:02PM +0100, Dirk Stöcker via Postfix-users wrote: > Hallo, > > > On my machine, the authoriative server (BIND) only listends on the > > the ethernet IP interface, while the recursive server (unbound) > > listends only on 127.0.0.1. It validates queries for my own domain, > > just like for any other. > > I wanted to prevent installing and caring for two software instances on such > a minor system. Both resolvers can be BIND if you prefer, I just like unbound as a recursive resolver, and it is easier to not confuse the two when they use different software and control utilities. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behavior of smtp_tls_security_level = dane
Hallo, On my machine, the authoriative server (BIND) only listends on the the ethernet IP interface, while the recursive server (unbound) listends only on 127.0.0.1. It validates queries for my own domain, just like for any other. I wanted to prevent installing and caring for two software instances on such a minor system. So two tasks for me: a) fix the internal DNSSEC issue Nothing to fix in DNSSEC, rather, split the auth and recursive resolvers. We'll see. Maybe I can convince bind to be a recursive resolver on the local interface and ask itself via the external interface for the own domains. Essentially your setup, but only with bind. I thought I did so in the past, but it also may be I simply forgot about it. I believe bind doesn't offer the easy way to simply check and add ad flags for it's own domains when used as recursive resolver. Or maybe I'll document situation and simply ignore the missing DANE for these two hosts ;-) For Freedom In Peace -- http://www.dstoecker.eu/ (PGP key available) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behavior of smtp_tls_security_level = dane
On Sat, Mar 16, 2024 at 11:04:46PM +0100, Dirk Stöcker via Postfix-users wrote: > From the server which has the local name server the answer has the > aa flag, but not the ad flag. That's expected when the nameserver in question is authoritative for the requested domain, no DNSSEC validation is performed, since the data is (presumably) from a trusted source. It is up to recursive servers to validate it as needed. Your configuration where the same server is both authoritative and recursive is not supported. The risk with trusting that AA-bit is that the server might be a secondary server for the zone, with an insecure channel for zone transfers, in which case the AA bit cannot be trusted. Postfix only trusts the AD bit from a validating local resolver, and trusting the AA bit would have be a new configuration option, but simpler to never mix authoritative and recursive service in the same nameserver process. On my machine, the authoriative server (BIND) only listends on the the ethernet IP interface, while the recursive server (unbound) listends only on 127.0.0.1. It validates queries for my own domain, just like for any other. > So two tasks for me: > a) fix the internal DNSSEC issue Nothing to fix in DNSSEC, rather, split the auth and recursive resolvers. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behavior of smtp_tls_security_level = dane
Hello, DANE TLSA records are strictly enforced when "well-formed", where well-formed also requires a plausible TLSA "associated data" field (expected length for SHA2-256 and SHA2-512 digests and valid DER encoding of certs or keys for matching type Full(0)). That's what I did expect. Starting with the fact that what I expect is also what should haven happened I reviewed the whole system. The reason somewhere lies in DNSSEC. The mail sending server is also the domain server for the internal target domain. When I send mail to the target from somehwere else DANE works (with updated TLSA). From the server which has the local name server the answer has the aa flag, but not the ad flag. I have to investigate what's broken here. Either a configuration change or an update broke something. It was hidden as no negative side effects were visible (I hate it when stuff fails and it's invisible, except in some logs). So two tasks for me: a) fix the internal DNSSEC issue b) monitor internal DANE as well Lesson learned: Not only external stuff must be monitored thoroughly. ;-) P.S. For https://www.postfix.org/TLS_README.html#client_tls_dane maybe the third paragraph could have added: "If there are usable, but mismatching TLSA entries, no mail is sent."? For Freedom In Peace -- http://www.dstoecker.eu/ (PGP key available) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behavior of smtp_tls_security_level = dane
On Fri, Mar 15, 2024 at 10:13:01PM +0100, Dirk Stöcker via Postfix-users wrote: > I recently did a misconfiguration of an internal mail server for a test > system and as a result broke the TLSA record. Exactly *how* was the TLSA record broken? Logs? And were alternative MX hosts available for the destination domain? ... Without technical details, your anecdotal experience can at best just elicit sympathy. > Postfix still delivered mail to the system now with Trusted instead of > Verified (BTW I find these two outputs texts misleading, each time I > check the logs I look for a reference server to know which of the two > is which, couldn't you find something more explicit?). That's not generally expected, because the default is not trust any WebPKI CAs, but perhaps you explicitly specified a non-empty smtp_tls_CAfile or smtp_tls_CApath? > That was a really unexpected behavior for me so I looked in the > documentation for "smtp_tls_security_level = dane" in > https://www.postfix.org/TLS_README.html#client_tls_dane and really there it > says "If TLSA records are published for a given remote SMTP server (implying > TLS support), but are all "unusable" due to unsupported parameters or > malformed data, the Postfix SMTP client will use mandatory unauthenticated > TLS." Well, were the TLSA records unusable (bad usage, selector or matching type parameters or bad data), or were they usable, but simply did not match the presented certificate chain? The former will lead to "encrypt", the latter will skip the MX host and either defer delivery or use another MX host. > Now I understand the rationale behind this. Still unclear what "this" is. Unusable TLSA records are treated as a signal to "encrypt", but do not signal an (impossible) authentication requirement. > You want to prevent mail breaking because of too many bad > configurations, but in this case I think a more strict DANE setting is > missing: If you want DANE for a particular destination, you can use "dane-only". If you want opportunistic DANE TLS (RFC7672), for random destinations with no *prior* expectation of security, then treating unusable parameters as "encrypt" makes sense. > * I agree that at the moment it can be a good idea not to enforce DANE for > "unsupported parameters" or "malformed data" (even though I think there > should be a way to make this an error). We'll agree to disagree about that. > * But I would expect that DANE is enforced when data is well-formed and with > supported parameters but simply wrong, like in my case old. That's actually the case. Well-formed, but "simply wrong" (not matching the cert chain) TLSA records are strictly enforced. Otherwise, what'd be the point of DANE TLSA records? > Would it be possible to add a "dane-strict" setting which enforces > correct DANE always, when there are TLSA records or at least > acceptable but not matching TLSA records (I assume changing "dane" > option is out of the question)? DANE TLSA records are strictly enforced when "well-formed", where well-formed also requires a plausible TLSA "associated data" field (expected length for SHA2-256 and SHA2-512 digests and valid DER encoding of certs or keys for matching type Full(0)). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
