On Fri, Apr 17, 2020 at 06:19:18PM -0400, Rich Felker wrote: > This reasoning is why I consider it harmful to limit use of DANE > records to situations where the DNS lookup is "trusted" to have been > validated -- it just encourages flipping a switch to "trust" servers > that shouldn't be trusted.
You have not thought this through. For example, Postfix also supports a mandatory "dane-only" security level, which means we have to know that the TLSA records are properly signed. > The right behavior (regardless of what any RFC says) is to use any > TLSA records you're able to lookup. There are (unsigned) domains where any attempt to look up TLSA records times out or otherwise fails. If DANE is to be downgrade-resistant, and if logging of DANE-verified connections is to mean anything in terms of actual resistance to downgrade attacks (otherwise opportunistic TLS is quite sufficient), then in fact validation is required, and TLSA lookups should not be attempted for MX hosts in unsigned zones. > If the configured nameservers are > validating DNSSEC and your link to them is secure, you get the full > protection DANE provides. If they're not, the behavior is no worse > (and in many ways better) than what you'd get by not having DANE at > all. Except that this does not actually work. > Yes an attacker could perform DoS by giving you invalid TLSA records > or MITM the connection by providing ones for a key they control, but > if you switch DANE completely off then an attacker in the same > position can do these things anyway. There's more to it than you've considered, and logging still needs to reflect the actual security achieved. -- Viktor.