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

[Warren Kumari <[e-mail]>]

<chair hat>

Hi there all,

First off, thanks for keeping this civil. This is an important issue (and one that we've skirted around in the past..), lets try and prevent it becoming contentions as well :-)

So, it seems (to me!) that both Eric and Andrew have perfectly sane and defendable positions, but diametrically opposed.
This is (IMO) something that we are going to have to resolve before this is published, so I am asking our AD to consider holding off...


</chair hat> 

So, how does the WG feel about a knob that can be turned to choose behavior? Something that can be set for the less secure manner for now, and then (the default) changed later? 
Security conscious / at risk folk would be able to turn the knob now...

Worst idea ever?


W

On May 4, 2012, at 11:10 AM, Eric Rescorla wrote:

> 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
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>