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

[Andrew Sullivan <[e-mail]>]

On Mon, May 14, 2012 at 07:55:35PM -0700, Eric Rescorla wrote:
> 
> * secure, bogus, indeterminate, or insecure [specified in section 4.1]
> * no response, DNS error, etc. [the state in question here]
> 
> The relevant point here is that in the case where you were expecting
> DNSSEC but you get some error in the last category, then in order
> to get security benefit from restrictive modes, you must treat that as
> if it were bogus. That's different from cases where you weren't
> expecting DNSSEC (insecure, indeterminate), and therefore you
> should just be ignoring the TLSA records.

I think the reason I find this discussion difficult is that I don't
get this "expecting" thing.  With DNSSEC, you have _no idea_ what to
expect.  What you do is ask for something, and get a response or an
error.  Either it is validatable or not.  You can expect a
DNSSEC-signed response on the basis of the DS at the parent side.

In the cases you're talking about here, however, you still don't know
what to expect even if the A or AAAA record you fetched before was
signed and validated and so on.  You might get NOTIMP, for instance.
As Martin Rex argued, that response is strictly consistent with the
relevant RFCs even if many of us think that it's the wrong way for a
server to reply.  I agree that a TLSA answer in that case adds nothing
to the security; but "just ignore the TLSA records" (which, _ex
hypothesi_, you didn't get under the scenario) would seem to be an
argument for "fall through to traditional TLS processing".  I thought
that's what you wanted _not_ to happen?

Best,

A


-- 
Andrew Sullivan
[e-mail]