On Fri, Apr 17, 2020 at 06:52:48PM -0400, Rich Felker wrote:
> > 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.
No, I have not. Read my message again, then try:
dig -t mx nist.gov
dig -t tlsa nist-gov.mail.protection.outlook.com
> 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.
But TLSA queries to unsigned domains still often run into lookup
failure. What then?
> > Except that this does not actually work.
>
> I think you misunderstood what I said.
No, rather you've not yet thought about the issues in sufficient
detail.
> > 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.
Also required for "dane-only".
> 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).
But unsolicited TLSA queries into unsigned zones don't work
(sufficiently often to make attempting to do so impractical).
--
Viktor.
