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

[Andrew Sullivan <[e-mail]>]

On Tue, May 15, 2012 at 12:23:13AM -0400, Paul Wouters wrote:
> 
> if you expect a dnssec signed answer (eg because you have a validated
> parental DS) but you did not, the reseult is what? bogus? 

Yes.

> But if there
> might be a zone cut in between the parental DS you have (eg the root)
> and the zone, it is indeterminate? 

If you're not sure whether there is a zone cut because you fell off
the end of a chain without determining that you were into provably
insecure space, then it's bogus.  Otherwise, it's insecure, not
indeterminate.  (DLV or a TA could make the space secure again, of
course, across a probably insecure boundary, in which case it's a
matter of the validation state again.)  For our purposes, you can
think of "Indeterminate" as "I don't have a trust anchor".  This is
the meaning in RFC 4033, which discusses the matter from the POV of
the resolver.

> Right now, a browser can just query for TLSA records to its local
> resolver, and make a decision based on the AD bit. If any filtering
> of DNSSEC is taking place, the local resolver should be returning
> SERVFAIL. Do we want the browser to extract more details with CD? Or
> should they just hard/soft fail based on their local settings? Should
> they find out if this would be "bogus" or "indeterminate", or is there
> no point?

It is possible that the browser could also use some future
to-be-invented API that provided the details without having to have a
full service resolver built in.

> warnings. It's really the same as disabling TLSA. Or else we're going to
> have to teach browsers to remember previous TLSA state and only warn
> when we knew the site used to publish TLSA, but now we are
> indeterminate.

Surely, that's just as bad an idea; the fact that the DNS used to
contain a AAAA record is no guide to whether a site is supporting
IPv6 today, by way of analogy.

Best,

A

-- 
Andrew Sullivan
[e-mail]