On Fri, Apr 17, 2020 at 06:27:27PM -0400, Viktor Dukhovni wrote: > 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.
I think you misinterpreted my above-quoted text to mean that you should treat timeout/servfail/etc. as absence of TLSA records. That is absolutely not what I mean or something I would ever advocate for. Only a success or nxdomain result is actionable. Anything else is necessarily tempfail, regardless of DNSSEC or DANE. If you have correct nameserver configuration that validates DNSSEC, either success or nxdomain is proof that the result was signed or the records are in a provably unsigned domain. In either case, the best action is to use the records you obtained. If the domain is unsigned, that's the domain owner's choice, and not something you need to second-guess. (I believe the choice of dane-only to enforce this, rather than just treating "unsupported parameters or malformed data" as a hard failure, is wrong.) > > 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. I think you misunderstood what I said. > > 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. I can see where it could be desirable to log whether delivery was made based on a TLSA record in a signed domain vs an unsigned one, and this necessitates being able to see the AD bit or equivalent. But it does not justify dropping all protections if you can't see it, just dropping the ability to log (or rather, warning in the log that all records look like potentially-unsigned ones). Rich
