On 26/11/13 5:41 AM, Chris Palmer wrote:
On Wed, Nov 20, 2013 at 1:36 PM, Yoav Nir <[email protected]> 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?
Thanks, Chris.To summarize, although there has been much discussion since version -06, most of it did not result in massive changes to the document, so IMO we don't need another WGLC. If anyone feels differently, please let me know by the end of this week.
Pasted below is the privacy considerations section, which is new to this version.
There is one thing that I think needs fixing before submitting: the IANA considerations section. It says that this document has no actions for IANA. This is wrong. IANA keeps the registry for HTTP (among other things) headers:
http://www.iana.org/assignments/message-headers/message-headers.xhtml So it should be something like 6. IANA ConsiderationsIANA is requested to register the header described in this document in the "Message Headers" registry, with the following parameters:
o Header Field Name should be "Public-Key-Pins"
o Protocol should be "http"
o Status should be "standard"
o Reference should be this document
Thanks,
Yoav
Here's a paste of the new section 5:
5. Privacy Considerations
Conforming implementations (as well as implementations conforming to
[RFC6797]) must store state about which domains have set policies,
hence which domains the UA has contacted. A forensic attacker might
find this information useful, even if the user has cleared other
parts of the UA's state.
More importantly, Hosts can use HSTS or HPKP as a "super-cookie", by
setting distinct policies for a number of subdomains. For example,
assume example.com wishes to track distinct UAs without explicitly
setting a cookie, or if a previously-set cookie is deleted from the
UA's cookie store. Here are two attack scenarios.
1. example.com can use report-uri and the ability to pin arbitrary
identifiers to distinguish UAs.
2.
1. example.com sets a Valid Pinning Header in its response to
requests. The header asserts the includeSubDomains
directive, and specifies a report-uri directive as well.
Pages served by the host also include references to
subresource https://bad.example.com/foo.png.
2. The Valid Pinning Header includes a "pin" that is not really
the hash of an SPKI, but is instead an arbitrary
distinguishing string sent only in response to a particular
request. For each request, the Host creates a new, distinct
distinguishing string and sets it as if it were a pin.
3. The certificate chain served by bad.example.com does not pass
Pin Validation given the pin set the Host asserted in (1).
The HPKP-conforming UA attempts to report the Pin Validation
failure to the specified report-uri, including the
certificate chain it observed and the SPKI hashes it expected
to see. Among the SPKI hashes is the distinguishing string
in step (2).
3. example.com can use SNI and subdomains to distinguish UAs.
4.
1. example.com sets a Valid Pinning Header in its response to
requests. The header asserts the includeSubDomains
directive.
2. On a subsequent page view, the Host responds with a page
including the subresource https://0.fingerprint.example.com/
foo.png, and the server responds using a certificate chain
that does not pass Pin Validation for the pin-set defined in
the Valid Pinning Header in step (1). The HPKP-conforming UA
will close the connection, never completing the request to
0.fingerprint.example.com. The Host may thus note that this
particular UA had noted the (good) pins for that subdomain.
3. example.com can distinguish 2^N UAs by serving Valid Pinning
Headers from an arbitrary number N distinct subdomains,
giving some UAs Valid Pinning Headers for some, but not all
subdomains (causing subsequent requests for
n.fingerprint.example.com to fail), and giving some UAs no
Valid Pinning Header for other subdomains (causing subsequent
requests for m.fingerprint.example.com to succeed).
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
