On Wed, Nov 20, 2013 at 1:36 PM, Yoav Nir <syn...@live.com> wrote: >> As I recall (perhaps incorrectly), our takeaway from IETF 86 was the >> removal of the 'strict' directive, since the notion of having a remote >> server provide a directive to override local policy is just escalating a >> policy arms race. > > That was issue #53. It was closed, and there was no consensus to remove > 'strict'. The only things missing from the draft is the closing of #57-#60.
Issue 53 (http://tools.ietf.org/wg/websec/trac/ticket/53) was not quite about the policy arms race. The policy arms race between public web site www.example.com and a given client's filtering TLS proxy is over: if the client legitimately trusts the TLS proxy (e.g. the TLS proxy's trust anchor is installed in the client's trust anchor store), then www.example.com cannot enforce its policy on the client; in effect, the proxy is the true client. On the other hand, if the client does *not* trust the TLS proxy, then the proxy will be "caught" either by pinning or by the usual "The server presented a certificate your operating system does not trust" warning screen. So I don't think it is possible or sane to promise to site operators that they can deny MITM powers to MITMs that the client trusts. As I (think we) intended it, strict was to mean "bypass the local policy of not applying pinning to chains that chain to local trust anchors" — i.e. as a way of allowing sites that install their own trust anchors on machines to also pin the keys of the servers that the local trust anchor signs. This would be for enterprises that want to have their own PKI and also strictly enforce it (to ensure that, e.g., internal.example.com never chains to a public anchor). The utility of this is debatable (but, I would argue, more than 0... potentially). There is a new draft -09 in our Git repo at https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-websec-key-pinning.xml. Any thoughts before I actually put it in the IETF tracker as the real -09? _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec