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

[Eric Rescorla <[e-mail]>]

On Mon, May 14, 2012 at 9:23 PM, Paul Wouters <[e-mail]> wrote:
> 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.

Well, it's a listed category in 4033. If it's a null category, that's fine.


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

Did not what? The case in question is that you get no answer or an
ICMP response or something.


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

Yes, I tend to agree, but it's clear that there's not consensus on this
point, so I'm focusing on describing the technical situation.

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

Yes, that's true, but I'm not sure I see the relevance. Obviously, under
non-attack conditions you would expect to see this with some frequency.


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

Which after all, might happen.


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

Personally, I expect browsers to not query for TLSA records at all,
for the reasons that AGL indicated earlier.



> 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 don't understand any of this. Even if you trust your resolver, there
are certainly ways for an attacker to suppress the response, so it's
always going to be the case that you need to know what to do
when you get no response. This is true whether the browser has
validation logic or not.


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

Yes, hence my original post.

Once again, *I* think it's silly to implement TLSA and then act in a way
that allows an attacker to force you back to the posture you would
have been in if you didn't implement TLSA. However, apparently
there is no consensus on that point. What we're discussing now
(at the chair's request) is how to characterize the security implications
of that implementation choice.

-Ekr