Re: [websec] HPKP: The strict directive and TLS proxies

[Chris Palmer <[e-mail]>]

On Wed, Nov 20, 2013 at 1:36 PM, Yoav Nir <[e-mail]> 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?