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

[Paul Hoffman <[e-mail]>]

On May 3, 2012, at 2:55 PM, Eric Rescorla wrote:

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

From the earlier thread on this topic, I do not think there is "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't even agree about it.

Just because I like actual proposals for text, I believe what ekr is proposing is changing the current:
   o  If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, this MUST cause TLS not to be started or,
      if the TLS negotiation is already in progress, MUST cause the
      connection to be aborted.
to:
   o  If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, or if a response is not received or the
      response has no data, this MUST cause TLS not to be started or,
      if the TLS negotiation is already in progress, MUST cause the
      connection to be aborted.

--Paul Hoffman