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

[Paul Wouters <[e-mail]>]

On Tue, 8 May 2012, Andrew Sullivan wrote:

> On Mon, May 07, 2012 at 04:16:37PM -0700, John Gilmore wrote:
>> I think that if the DANE TLS implementation can't get either a
>> dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA
>> rrset, then to meet its security responsibilities, it has to fail to
>> connect.
>
> This is a strong statement, and is perhaps what ekr was asking for
> too.  It's that "fail to connect" that bugs me.  For it means that, if
> a client is TLSA-aware and it happens to find itself in some sort of
> environment in which TLSA records don't work, or DNSSEC records don't
> work, or both, there is exactly one thing it can do: foil all TLS
> connection attempts.

We really have no other choice. Your mother did not tell you when you
were young "Always lock the door if you are the last one leaving the
house, except when you think someone else might arrive home first, in
which case put the key under the door mat". She just said "always lock
the door" and you left the key under the mat sometimes anyway.

> Just to be clear, what that does it cause the user to turn the browser
> into a TLSA-unaware client.  If I had to bet, I'd bet that it will
> persist and that it will itself become a barrier to operation.
>
> It feels to me like this discussion lies right on the barrier of
> "protocol" and "local policy", and that may be the reason it appears
> to be intractable.  On the one hand, I can't believe anyone wants a
> requirement that actually increases the chances people will make
> connections without TLS, by making TLS impossible in some networks
> where it sort of works today.  On the other hand, I understand (and
> agree with) the analysis pointing out the attack available if a
> complete non-response causes fall-through to traditional TLS
> processing.  I'm wondering whether implementation or deployment advice
> (perhaps in another document) is something that's not just nice to
> have, but needed.

Let's leave those decisions to the browser vendors. They've gone through
this before and will go through this again. Ultimately, the biggest real
use-case is the hotspot case, and currently, it is mostly the browser
that detects this first. That has to change, and once the OS detects
this first, it can provide hints to the browser, and ultimately, even
have the browser start a sandboxed sign-on window to authenticate and
allow contained spoofed DNS before opening up the entire machine to DNS
and port HTTP(S). If networks are still DNSSEC broken after
authentication, and they are blocking port 53 and they are blocking fall
back resolvers over port 80 and/or 443, then really, what else is there
to do then hard fail?

Paul