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.

Reply via email to