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