On Wed, Apr 25, 2012 at 11:47 AM, Paul Wouters <paul@xxxxxxxxx> 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/