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

[Paul Wouters <[e-mail]>]

On Mon, 14 May 2012, Eric Rescorla wrote:

> I don't think this is what we want.. There appear to be five relevant
> states:
>
> * secure, bogus, indeterminate, or insecure [specified in section 4.1]
> * no response, DNS error, etc. [the state in question here]

We had these discussions before, where there is a disagreement about
some cases where you are not getting some responses and what state it
is supposed to be. I'm not sure we all agreed in the end - I thought
some people argued that "indeterminate" does not really exist.

> The relevant point here is that in the case where you were expecting
> DNSSEC but you get some error in the last category

if you expect a dnssec signed answer (eg because you have a validated
parental DS) but you did not, the reseult is what? bogus? But if there
might be a zone cut in between the parental DS you have (eg the root)
and the zone, it is indeterminate? I think for TLSA, these should both
be treated the same, as bogus.

> 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.

You cannot know when you were NOT expecting DNSSEC unless you do DNSSEC
and you a get a validated anwser that leads to an end of the trust chain
before it reaches the domain you were interested in. So an attacker
would also prevent you from knowing that. And if you know a domain is
insecure, you don't even need to query for TLSA records, unless your
model assumes a full validator logic built into the browser, as opposed
to using a trusted validator on localhost.

Are we expecting browsers to just query for TLSA records and ignore
those received without AD bit? Or are we expecting them to implement
full resolver logic?

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?

>> I'm also not sure why the statement is limited to certficate usage 0 and
>> 1. Is that because you assume no PKIX alternatives are available and
>> thus it always has to abort for insecure/indeterminate?
>
> The security logic is different for restrictive records and additive records.
> Say that you're not willing to hard fail on TLSA failures but you're willing
> to suppress error warnings if you get resolvable records of type 2 and 3.
> Then you are getting security benefit for those records, but you're not
> getting any security benefit if type 0 or 1 records exist.

Now I'm completely lost. Usage 0 and 1 is for pinning PKIX, so if you
want to use TLSA to avoid rogue CA's, you can't suppress those error
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.

> Arguably, it would be best to serve two different classes of records to
> make this clearer.

I'm not sure that matters, because if you cannot get those records, eg
an indeterminate answer, you cannot make a decision based on a supposed
different class of record you can't receive.

The only way out to signal something about hard/soft fail for TLSA
outside the DNS would be to put a market in the certificate. But then
we're back to square one with rogue CAs.

Paul