Re: [dane] Behavior in the face of no answer?

[Paul Wouters <[e-mail]>]

On Fri, 4 May 2012, Andrew Sullivan wrote:

> This isn't "will cause TLSA not to work", it's
> "can't use TLS at all on that system".

But you cannot tell the difference between maliciously "not supporting"
and "pretending to not support so you will not request TLSA".

> I have no idea whether there
> are such configurations in the wild, but they're pefectly acceptable
> under the standards we have.  It seems to me, therefore, that one
> needs to be able to turn off TLSA use under such circumstances, if
> we're going to say that such failures must "fail hard".

These can certainly happen. But an application or device can then use
its own validating resolver. This only becomes a problem when there is
both a broken old DNS deployment, AND additional firewalling preventing
one from bypassing that old DNS deployment. I'm willing to call those
networks "broken by design", and I'm fine with hard failing. But I don't
have to man a support desk.

This does assume that if an application that wants to support TLSA would
have to have a validating resolver built in to fall back to, along with
a root key. Alternatively, the local policy could be that if generic
DNSSEC is failing (eg a query to the a root server for a root zone record
fails to come back with proper RRSIG/NSEC* records) that no attempts to
use TLSA are done. But that is a local policy decision, one that I would
override to hard fail (but my father probably would be ok with)

Paul