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

[Eric Rescorla <[e-mail]>]

On Fri, May 4, 2012 at 7:44 AM, Andrew Sullivan <[e-mail]> wrote:
> On Fri, May 04, 2012 at 06:48:20AM -0700, Eric Rescorla wrote:
>> On Fri, May 4, 2012 at 4:29 AM, Andrew Sullivan <[e-mail]> wrote:
>> >
>> >    1.  The attacker is able to undermine some CA.
>> >
>> >    2.  The attacker is actually on-path and going to undermine my
>> >    connection.
>>
>> I'm confused by this answer: DANE (for the two constraints modes)
>> only offers security value if *both* of these things are true. If the
>> first is not true, then a PKIX certificate is sufficient to distinguish
>> between valid users and attackers and in the second is not true,
>> then even an attacker with an invalid certificate cannot get
>> your packts.
>
> Yes, of course.
>
> Your proposal is that, if I have a TLSA-enabled client, I
> automatically lose TLS support _for anything_ in the event I'm in a
> network with poor DNS support.  I was trying to argue that there is
> another sensible alternative: I could make a decision to allow TLSA
> responses not to work in some cases, because I think it is more likely
> that the network is broken than that (1) and (2) are both true.  But
> I might in general not trust CAs, and think that (1) is more likely
> that (2) most of the time, and therefore normally want to prefer
> TLSA.  Therefore, I ought to be able to decide to proceed in the face
> of the failure to get a TLSA record at all.

Again, I don't understand your reasoning here. It's not a matter of 1
*versus* 2. If you proceed in the face of no TLSA record, I claim you
might as well not do the TLSA check.


> Perhaps one would argue, however, that this amounts to saying, "I need
> to be able to turn TLSA off."  I could live with that.
>
> I am still opposed to anything that says we have to treat some
> reponses that are not DNSSEC-bogus "as bogus", because I think it
> muddies the DNSSEC evaluation waters even more than they already are.
> Could we come up with another way of saying this?  How about this:
>
>    In the event that all DNS queries for the TLSA record time out, or
>    return with RCODE 1 or RCODE 4-15, TLS MUST NOT be started or,
>    if the TLS negotiation is already in progress, MUST cause the
>    connection to be aborted.  Under these conditions, a user agent
>    MUST disable TLSA queries in order to undertage a TLS connection.

I don't really see how to operationalize this in a client in a useful way.


> Note that this does _not_ cause the connection to fail under the case
> we usually call "NODATA".  The case I mentioned yesterday, where AD is
> set and the upstream doesn't give you the DNSSEC data and you have a
> NODATA response is, AFAICT, just a case where there is no TLSA RRset
> and shouldn't result in TLS failure.

But the problem is that this is indistinguishable from the case where there
*was* a TLSA RRSET and you have a network attacker.


>  FWIW, I think the above is
> probaby too strong, but as long as we have something expicitly telling
> people that, if they thing DNS is broken where they are they need to
> turn of TLSA processing (i.e. a clue to implementers that they need
> this knob), I can live with it.

I'd rather not get bogged down in the exact RFC 2119 language and
discussion of what knobs must be provided just yet. But I do think it's
useful to think about this from the perspective of the implementor.
For convenience, consider the case of the browser. Currently, the
browser's algorithm is simple: check the PKIX cert and if it's valid,
connect and if not show a scary red dialog. [I'm ignoring cert pinning
for now.] And it's generally agreed that one should only proceed
past the scary dialog if either (a) you don't care who you are
connecting to, like in a captive network portal or (b) you are really
sure you are in a secure network environment.

Now, consider the perspective of an implementor who adds DANE
support for usages 0 and 1. The first arm of the decision, PKIX valid,
now becomes three branches.

- Verifiably no TLSA records via DNSSEC or Insecure/Indeterminate zone:
  continue with PKIX validation.
- Verifiable TLSA records via DNSSEC: PKIX validation plus the TLSA check
- Non-response: ???

Now, the implementor has three choices in this final arm:

1. Proceed with the TLS connection. (soft fail)
2. Show the scary red dialog. (hard fail)
3. Refuse to connect under any conditions (really hard fail, the way you
do with pinning).

I claim that if you do (1) you might as well not bother with the TLSA
check at all, since the attacker can just bypass it. I assume you are
saying that one should do (2)? I think that's fine, as long as that's
also how you treat other TLSA failures, such as certs which aren't
in the TLSA list. If you treat this case preferentially, then attackers
will just simulate it.

Important note: I am not claiming that route (2) is good. If the
infrastructure is indeed as bad as you say, then users will find
themselves having to click through all the time and DANE is likely
not a useful signal.


>> Again, this is logical, but as far as I can tell it obviates the security
>> provided by DANE. I'd like to repeat the question I asked in my
>> previous message: can you describe a set of attacker capabilities
>> which would be sufficient for an attacker to mount a successful
>> attack on TLS pre-DANE but would not post-DANE, provided
>> that clients react to TLSA non-response by falling back to pre-DANE
>> behavior?
>
> No, and I never thought that was the point of TLSA.  I thought the
> point of TLSA was to enable people to use TLS, provably securely
> but without the X.509 PKI infrastructure, if they wanted to.
> Usability enhancements are security improvements too, IMO.

TLSA includes two types of records:

1. Records which constrain the set of valid certificates but which still
require PKIX validation of the certificate (Usages 0 and 1).
2. Records which allow a client to use keying material which would
otherwise not pass PKIX validation (Usages 2 and 3).

What we're talking about here is Usages 0 and 1. I agree that the
analysis is different for usages 2 and 3.

-Ekr