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

[Paul Wouters <[e-mail]>]

On Fri, 4 May 2012, Andrew Sullivan wrote:

> As a client, you could be making a decision about what is more likely:
>
>    1.  The attacker is able to undermine some CA.
>
>    2.  The attacker is actually on-path and going to undermine my
>    connection.
>
> In many cases, one might decide that (1) is more likely than (2), and
> therefore decide that TLSA is a better thing to rely on.  During
> deployment, however, one might be willing to think that (1) is less
> likely than, "I am in a coffee shop, and these people bought crappy
> infrastructure."  In that case, one might want to be able to fall back
> to the way we actually do this today.

Where "fall back" in this case means, "click OK to the 10 certificate
warnings popping up from my facebook, twitter, encrypted.google.com and
other tabs" that just got MITM's to the coffee shop "press ok to
continue" portal page on a self signed cert on port 443.

That scenario is lost with PKIX as well as TLSA.

> I imagine that, over time, the tolerance for the broken infrastructure
> will go down, and the fall-back decision will be less and less
> attractive.  But if the protocol says that once a client supports
> TLSA, any not-fully-modern DNS environment just means "no TLS", then
> we will be promulgating a standard that cannot be deployed.  We might
> as well not publish it.

>From the protocol point of view, this should be a hard fail. However,
I do not believe in the soft vs hard fail distinction in browsers, and
those vendors seem to implement things more in a scale from silently
ignore to adding more red colour depending on how hard they believe
the failure to be.

Overriding a protocol hard fail is really the overriding local policy
of the application. But in the protocol specification, hard fail should
mean hard fail, and it should not take that local policy into account.

Paul