[dane] Behavior in the face of no answer?

[Eric Rescorla <[e-mail]>]

I've been reading -20 and I'm not sure I understand the behavior that section
4.1 is supposed to say. Consider the following case:

I am trying to connect for the first time to https://www.example.com/,
which is signed. I go to retrieve the TLSA record, but when I do so,
the request times out. What do I do? There seem to be two options:

(a) Treat this as a hard failure and abort the connection.
(b) Treat this as if I have an empty TLSA response and continue with ordinary
TLS.

I claim that the right response from a security perspective is clearly (a): hard
fail. If you agree with me, then jump to "2. DOCUMENT TEXT" below. If not, keep
reading.


1. SECURITY ANALYSIS
The basic security setting in which CA constraints and service certificate
constraints are useful is one in which:

(a) The attacker has a valid certificate for the target domain, but not
the same as the certificate issued to the real server.
(b) The attacker has enough control of the network to get the victim
to connect to his server.

Generally, (b) means that the attacker is on-path to the client or the
server.

What makes DANE work is that it provides an independent cryptographically
verifiable check on the server certificate, thus excluding the attacker's
certificate. Even if the attacker can force traffic to him, then, the
certificate
won't be acceptable. If the attacker can force you to ignore the
information in DANE, then DANE offers minimal security guarantees.
If clients treat TLSA RR requests without responses (i.e., timeouts) as
if they were empty TLSA responses and continue with TLS as usual,
then any attacker who can block DNS responses (i.e., anyone who
is on-path to the victim, at least) can downgrade you to ordinary TLS.
So, I think it follows that non-responses (or SERVFAILS or any other
resolver error) must be treated as hard failures and cause aborts.

Note that the security context for DANE is different from
that of many DNS contexts, because in many such contexts,
non-response means you just don't resolve so you fail hard
anyway. But here, you fail to a weaker security position.

2. DOCUMENT TEXT
As I said above, I find the document kind of hard to read on this point.
S 4.1 refers to the RFC 4033 definitions and says that Bogus must
be hard-failed and that Insecure and Indeterminate must be treated
as if there were empty TLSA sets and you continue with TLS. So,
the question is whether non-response is Bogus or not. Here's
what 4033 says (http://tools.ietf.org/html/rfc4033#section-5)

 Bogus: The validating resolver has a trust anchor and a secure
      delegation indicating that subsidiary data is signed, but the
      response fails to validate for some reason: missing signatures,
      expired signatures, signatures with unsupported algorithms, data
      missing that the relevant NSEC RR says should be present, and so
      forth.

But in this case we don't have an invalid response, but instead a
non-response, so its not clear to me this falls into Bogus.

I'm not steeped in all the DNSSEC lore, so maybe there is a wide
agreement that nonresponse == bogus, but I don't get that clearly
out of the document. IMO, DANE would benefit from stating this
clearly.

-Ekr