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

[Andrew Sullivan <[e-mail]>]

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.

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.

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

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

A

-- 
Andrew Sullivan
[e-mail]