25 Jun 2012 22:35
Should security requirements be MUST?
Phillip Hallam-Baker <hallam <at> gmail.com>
2012-06-25 20:35:54 GMT
2012-06-25 20:35:54 GMT
An issue that appears to cause a lot of controversy out in WGs is the issue of whether a security requirement should be stated as a SHOULD or a MUST. While it may appear obvious that a specification should prohibit a bad practice, I now think this is the wrong approach. Security is a balance of concerns that are often in conflict. When the only concern is confidentiality, the best approach in cases of ambiguity is usually going to be to refuse any action that might lead to disclosure. But this approach is inevitably in conflict when service availability is the prime concern. When a specification says MUST in relation to a security concern it most often says 'MUST refuse' or some other action that turns into 'MUST break'. These are not decisions that the specification writer is in a position to judge. The only party that can make these judgments are the application developers who understand the context in which the application is to be deployed. This is not an abstract concern. In recent months we have had two cases where IETF working groups have take one approach and industry has taken the other and in both cases the point at issue was whether a specification should provide security advice or whether conformance should require a specific security policy. I don't think anyone is going to deploy DANE on a large scale with the MUST reject feature implemented the way that the authors imagine. Unless we have a means for automatically updating the DANE records to the SSL service that the relate to the data in DANE records is just not going to be accurate enough for direct client enforcement anyway. Nobody uses DKIM policy records without some form of curator being involved, why expect DANE to be any different. On PKIX we have nonsense on stilts. The industry wants to use a feature of X.509 but the PKIX specification mandates that this can only be used if marked so as to mandate rejecting backwards compatibility with deployed products (including Safari). This seems a rather obvious shortcoming in the specification to me. But at root the problem is that nobody with sense is going to be looking to a consensus based process for direction on security policy. A consensus based process can certainly advise but only stakeholders can make an actual decision. -- -- Website: http://hallambaker.com/