Phillip Hallam-Baker | 25 Jun 2012 22:35
Picon

Should security requirements be MUST?

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/

Gmane