On Wed, Apr 25, 2012 at 11:47 AM, Paul Wouters <paul(_at_)nohats(_dot_)ca>
wrote:
On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote:
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.
So you are saying that this MUST does not matter because MUSTs can
always be overridden?
My view is that the correct approach in this case is to use a SHOULD.
That is also what it says in 2119:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
I think that 'causing harm' needs to be considered very narrowly here
as it seems pretty clear that the original context is talking about
harm to network operations.
If we think that local security policy is going to override then we
really have no choice but to use a SHOULD if we are taking 2119
literally.
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.
That is unfair on many levels, not least because 1) the Chrome guys
were the people who found the issue and 2) this was not a case where
revocation could have helped since the CA had no idea which certs had
been issued.
As I explained in the following discussion, what was most important
was to detect and report the security policy anomaly even if it was
not going to be sufficiently reliable to hard fail on. Of course what
would be the best case would be an Internet that didn't have such a
high degree of inherent unreliability. But that is not an option at
present.
Proposing to mandate behavior in the expectation of being ignored is
irresponsible.
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.
No, it means that you cannot address this particular problem with a
reductionist approach. We have already deployed a technology that
provides a partial fix to this problem.
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.
That is true. What I am arguing here is to not build a second
infrastructure that is going to fail in exactly the same way that OCSP
is failing.
If you subscribe to the right key you will have my omnibroker proposal
which proposes a way to use both DANE and OCSP without the current
failure modes. Otherwise I can send you the PDF.
--
Website: http://hallambaker.com/