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

[Andrew Sullivan <[e-mail]>]

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.

> In browsers there will likely be a switch to "Use DANE TLS" just like
> today there's a preference checkbox in Firefox for "Use SSL 3.0" and
> "Use TLS 1.0".  When behind a broken coffeeshop gateway, the human may
> need to manually turn off that switch.

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.

Best,

A

-- 
Andrew Sullivan
[e-mail]