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

[Tom Ritter <[e-mail]>]

On 4 May 2012 10:42, Nicholas Weaver <[e-mail]> wrote:
> So here's my proposal: Actually check the network for b0rkenness!
>
> The browser, on startup, or when the local IP address changes, conducts the following test:
>
> It checks, using three known sites with TLSA records (provided by the browser vendor, with deliberate redundancy to prevent a TLD outage from being a problem), to see if it can receive and validate a TLSA record using DNSSEC for at least one of the three sites.

I don't think will actually help anything.  The attacker will just
block ALL TLSA records, not just for the target site he intends to
MITM.



Fail-close vs Fail-open when you can't get the TLSA record is OCSP
hard-fail vs soft-fail all over again.  I'd like Hard fail, but no
matter what we say, no browser will implement it.  If mandating
hard-fail in the spec causes clients to NOT implement DANE (as opposed
to just ignoring the recommendation) - I don't think we should do it.



HOWEVER!  WE HAVE A SOLUTION!  Actually, Chrome has a solution, and it
already works. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
DNSSEC Stapled Certificates

Put the DNSSEC chain *in the TLS certificate*.  This won't be blocked
by a MITM, and if you receive a self-signed certificate with a valid
TLSA chain in it, it's valid.  The TLSA chain is signed, so it doesn't
matter _how_ you receive it, as long as the signatures all match up.

Now this is a solution to the broader problem of delivering the TLSA
record to the client for verification, it's not a solution to
hard-fail vs soft-fail for TLSA queries. (I already gave my opinion on
that.)  And it's clear that this solution should not go into this RFC,
and that we need to either:

 - recommend soft-fail (bad)
 - recommend hard-fail (potentially bad, if it stops adoption)
 - punt, and let everyone do what they're going to do already: soft-fail

But this idea, which I think could turn into a RFC fairly easily, get
implemented in browsers in relatively short order, and get implemented
in webservers in considerably longer order - can solve the general
problem.

-tom