On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote:
The browser providers do not hard fail on OCSP because doing so would require them to wait for the OCSP response within the TLS handshake and this is considered an unacceptable performance degradation.
And with the current ocsp.entrust.net issue, that would be a two day performance degradation? There is also the privacy issue. But all of this is off-topic.
Section 4 of the draft mandates a client hardfail if the DNSSEC trust chain cannot be obtained. This is essential if the client is going to use DNSSEC to establish certificate constraints just as certificate revocation is an essential part of the PKIX model. But no browser provider can expect to succeed with a product that simply stops working when the user tries to surf the Web from a coffee shop.
hotspot detection for temporal DNS failure/spoofing mode is what browsers need to support/implement. It is no different then the fix they needed when we opened our browser at a coffee shop and all tabs destroyed themselves reloading into hotspot login pages.
Since the coffee shop problem is not intentional we might imagine that it will eventually go away. But this puts DANE in a deployment deadlock bind. Nobody is going to fix their coffee shop routers until there is a need to and that need won't exist until the coffee shop routers are fixed.
I suggest you run with dnssec-trigger software for a while and then come back to this assertion. We do not need coffeeshops to fix anything, we need better DNSSEC integration on our laptops and phones.
Rather than mandating hardfail or any particular client behavior, the specification should simply state that the client MUST conclude that the DANE status of the certificate is invalid and then leave the client to decide on what course of action to take. This will depend on the circumstances of the particular user and the client provider's assessment of the reliability of the DANE data and might range from do nothing to send a security policy violation notification somewhere to hardfail.
In all IETF protocols, there is the "local policy overrides", yet we don't add it specifically to every MUST in the protocol documents. Additionally, the browser can fail the connection and terminate the TLS and provide the user some feedback with a local policy override, and then the brower complies to both the hard fail requirement, and your 'too big too fail' argument.
Contrary to the assumptions of the specification authors, hard fail is not the best option. It is not even the best option in the case that the users are dissidents.
Tell that to the chrome users in Iraq that are still alive and not in jail getting tortured. If anyone is going to sacrifice the one for the many, I sure as hell hope it won't be protocol designers.
But you can be sure that Iran, Russia and China will be doing so the minute any client started to make use of DANE. These countries can (and will) make use of a client hard fail to ensure that people don't use browsers that might be used for 'information terrorism' or freedom of speech as the rest of us call it.
Sure. Any data can be blocked. You work around the block with tunneling and then use the actual DANE information for your own protection and safety within the tunnel. Suggesting the block means you might as well not add security in case there is no block, or you can break through it, is wrong.
But the DANE approach is too dogmatic to succeed.
All your arguments against dane are equally valid/invalid for OCSP with hard fail, which you seem to be a proponent of. I fail to see the consistency in your reasoning. Paul