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

[Eric Rescorla <[e-mail]>]

On Tue, May 15, 2012 at 4:13 AM, Andrew Sullivan <[e-mail]> wrote:
> 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?

Let's take a step back.

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"

Because the signature is what secures the DNSSEC response (assuming
 end-to-end resolution), when you get an unsigned response, no
response, or an error like NOTIMPL, if you are in condition S you need
(at least if you want to be secure) to make the most pessimistic set
of assumptions about what the response would have been if whatever
error (or attacker behavior) caused you to get what you got had not
supervened. On the other hand, if you are condition I, then you
should be returning a response. It's still not cryptographically
secure, but there is no reason to believe it would have been.

Presumably DNSSEC does in fact know how to distinguish these cases,
else any unsigned response of any kind would lead to resolution
failures. What we are talking about is extending that logic to a
different set of security requirements.  What makes this case
different is that in the case of the A record, the most pessimistic
response is "does not exist". In the case of the TLSA record (types 0
and 1), the most pessimistic response is "exists and forbids the
certificate I am about to get".

-Ekr