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

[Andrew Sullivan <[e-mail]>]

On Tue, May 15, 2012 at 05:16:39AM -0700, Eric Rescorla wrote:
> You're a resolver.
> 
> You generate a request for a given RR, say an A record. It comes back
> with no signature at all. Under one set of information about the state
> of the world (call that S), you generate a resolution failure. Under
> another set of information (call that I) you consider it a result to
> the application but tell it that the request isn't DNSSEC signed. When
> I say "expecting DNSSEC", I mean condition "S"

Are you talking about a case where by, for local policy reasons, if
you don't get a DNSSEC-validating response, you produce an error
(probably the functional equivalent of SERVFAIL) for consumption by
the calling application?  The reason I ask is this:

> Presumably DNSSEC does in fact know how to distinguish these cases,
> else any unsigned response of any kind would lead to resolution
> failures.

How?

If you're talking about the description of the world as I interpreted
above, then unsigned responses of any kind _would_ lead to resolution
failures.  That's why nobody would turn that knob on except in very
narrow circumstances.

If you're talking about normal operation of a validating resolver,
then you can distinguish between "this response is signed and
validatable, and everything in the delegation chain is too" (secure);
"this response is signed but not validatable in some way", or, "this
response is not signed but I can prove it should be" (bogus); "this
response is not signed and I can prove that it needn't be"
([probvably] insecure); "I don't know about this case"
(indeterminate).  But these states don't extend to the errors (except
Name Error).

In the case of an error or simple non-response, you just don't have
the data.  You can't draw any conclusion.  Normally, you don't have
to, of course: if you don't know the A record or SRV record or
whatever, you can't do anything more, and your action fails.  (This is
not "does not exist", but "I can't find it".  For a naive user this
difference might not matter; "the site is broken".  But it does matter
for the purposes of caching and so on.  The possibility of a bad cache
is part of why I don't want to say "treat as bogus" for this purpose.)

In the DANE case, as you point out, what we're doing is adding to the
DNS supplementary data about a different data path.  That's the reason
that, when you get an error or don't get a response, you need to draw
a conclusion.  This is an unusual thing to do with the DNS.

I therefore think you're right that, if for use case 0 or 1, the
responsible deployer would want the attempted connection to fail.
That's the security the additional data (the TLSA record) is supposed
to offer.  I've argued that approach is dangerous except in really
unusual circumstances, because it seems likely to result in surprising
random failures sometimes.  One of those failures is bound to cause
people to say, "Turn TLSA off," and then we lose all the TLSA
features.  Alternatively, it will cause people faced with a TLS
negotiation failure to fall back to no-TLS versions of whatever
they're using (which is probably spelled "http" for this worry), and I
think that's worse.  Surely, some people will deploy TLSA in use 0 or
1 without understanding the failure modes ("more security is better",
"turn it up to 11", and so on).

It seemed to me that the proferred additional text explained the above
(the upshot being that use 0 and 1 are both very close to useless).  

Best,

A

-- 
Andrew Sullivan
[e-mail]