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

[Nicholas Weaver <[e-mail]>]

On May 4, 2012, at 5:12 AM, Nicholas Weaver wrote:
> This is why browser's have given up on the other solution for the bad CA problem: Certificate Revocation Lists.  Because an attacker can block the CRL check, and the CRL check is NOT mandatory (they are unreliable enough that its not treated as a hard fail), CRLs are useless for blocking attackers.

For those not familiar with the context for the paragraph above:

http://www.imperialviolet.org/2012/02/05/crlsets.html

Chrome is abandoning the use of CRL lists for the browser, because of the "soft fail" nature, which means that CRLs only work when not under attack.  DANE for CA certificates with "fail open" is just the same as a CRL check.  And DANE effectively requires client-side validation.


Which means there are three cases:

A:  Client can't receive ANY DNSSEC at all when communicating directly with the network [1]

B:  Client can't receive ANY TLSA signed records...

C:  Client CAN receive valid DNSSEC and TLSA records but CAN'T get a TLSA (or NSEC/NSEC3 proof that it won't find one) for the site in question.



C clearly MUST be treated as an attack, and DANE MUST be fail closed in this case.



A and B are different.  It COULD be a broken network, or it could be an attack  (And based on Netalyzr, I think B is rare, its mostly A).  But an attacker can always make his attack look like A, so 'fail open' is clearly wrong.



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.


If yes, any failure to fetch the proper TLSA record or NSEC proof results in immediate 'fail open' when TLSA records are not received, as it is case C.


If no, DANE goes into a "Fail Scary" mode, akin to how browsers treat self signed certificates:

The browser MUST notify the user that the network is broken: its not allowing the browser to fetch DNS records needed to authenticate connections.  The user MAY override it and disable DANE validation, but the user is on notice that:

1)  The network is not allowing secure communication
2)  Its the network's fault, so go blame your network kit