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

[Eric Rescorla <[e-mail]>]

On Thu, May 3, 2012 at 7:36 PM, Andrew Sullivan <[e-mail]> wrote:
> On Thu, May 03, 2012 at 07:14:33PM -0700, Nicholas Weaver wrote:
>>
>> An IN-path adversary doesn't need to manipulate the A or AAAA records to get you to connect to their server.
>>
>
> Ah, ok, so we're talking about someone who can both intercept and
> redirect your connection to a target address and block DNS responses
> from getting to you but who cannot re-engineer DNS responses for you
> (obviously, because it'd fail at the root trust anchor).  Ok, now I
> get it.

Yes, this seems like the only threat model of real concern here,
since if you are dealing with an attacker who cannot do this,
then there is no need to authenticate their cryptographic keys
at all: you can just use unauthenticated DH (or RSA) key
exchange.



>> Since the adversaries of concern are likely to be in-path, not just
>> on-path, this is a serious concern and DANE when it can't get the
>> record it MUST hard fail lest it be useless in the face on an
>> in-path attacker, which is critical since the goal of all this
>> cryptomagic is to deal with in-path attackers.
>
> Surely this is a matter of local policy?  That is, it's probably a
> pretty good idea if it fails, and if you know what you are doing you
> probably want to say "fail if I can't get a TLSA response at all"; but
> during deployment and roll-out (as someone already argued up-thread)
> this is simply an unrealistic requirement: people are going to be
> behind broken devices for some years now, and a protocol-required hard
> fail requirement will either be ignored or else will delay deployment
> until we complete upgrading the Internet.  I suggest while we are
> waiting for that, we might want to work on DNS2 and TLS2.  If that's
> not enough, I'm sure we can find some more windmills.  Alternatively,
> we could just let people fall back to the infrastructure we have.
>
> Note that there remain _plenty_ of DNS servers deployed in the wild
> which, if you ask them for an RRTYPE they don't know about, spit up
> with NOTIMP, SERVFAIL, and all manner of other crappy nonsense.  (We
> were just having a bunfight about that over in SPFBIS a month or two
> ago.)  Turning off TLS for anyone whose client knows about TLSA, but
> who is trying to go to a service offered by someone employing a broken
> DNS server like this, is not reasonable.
>
> Speaking as an operator, I can tell you that if the protocol says
> "hard fail if I don't get a TLSA answer", I will tell all my customers
> not to use TLSA; the alternative is to make my customers mad at me the
> day someone's connection from some crappy hotel network fails.  I'd
> hate to be put in that position.

While I understand that these operational constraints, I'm having
trouble understanding what security benefit DANE offers if one behaves
as you suggest, since it seems the attacker can simply force you to
ignore any records that DANE provides.

Perhaps it would be useful to go back to first principles and ask
about the threat model. Can you describe a set of capabilities which
would allow successful attack on TLS in the current environment
but would not allow attack with DANE if TLSA nonresponse
for signed domains is treated as if there are verifiably no TLSA
records?

Thanks,
-Ekr