[websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors
This was raised during our discussions in Atlanta, and continued on the mailing list under http://trac.tools.ietf.org/wg/websec/trac/ticket/53 As discussed during Atlanta, the way that pinning is currently implemented within Google Chrome, pinning is only enforced as it relates to so-called public trust anchors (eg: those shipped by default as part of a browser or OS installation, not those installed by a user). The motivation for this was and is simple: If you have sufficient local privilege to install additional trust anchors on a device, then it's presumed you have sufficient privilege to take any number of other actions, including disabling pinning enforcement entirely. As such, having the UA disable enforcement selectively is strictly less worse, from a security perspective, than having the UA disable enforcement entirely, and still provides significant benefit through the reduction of risk through public trust anchors. However, this creates an interesting split between the specification language and implementations. In draft-04, we've tried to clarify this through the text in Section 2.6, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.6 , along with the addition of a strict mode, as described in Section 2.1.4, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.4 While there is an open question as to whether or not such user-agent behaviour is appropriate to specify here, does the group feel the proposed text sufficiently addresses the issue as originally raised? ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence
This was raised with http://trac.tools.ietf.org/wg/websec/trac/ticket/55 , as a concern about the interaction between static/preloaded pin entries and those that were noted later (eg: through the observation of the header) In draft-04, Section 2.7 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.7 addresses this by indicating that UAs MUST use the newest information available. Note: This does not normatively describe how a UA must determine newest. The assumption here is that this represents the newest observed, but the question is whether or not that should be explicitly specified. For example, imagine a UA that supports automatic updates to Preloaded Pin Lists. One interpretation of newest information would be to look at the most recent update to the preloaded pin list as a whole. Another interpretation of newest information may be to look at the date/time that the entry was originally added/updated in the preloaded pin list. Imagine this UA had a preload for Site 1 to a set of pins, with the preload created at T=0. Later, at T=5, it observes a Max-Age of 0, effectively unpinning the host. At T=10, the UA vendor ships a new update to the preloaded pin list that adds Site 2, but which has not been updated to unpin Site 1. Under the first interpretation of newest information, Site 1 would be reactivated, by virtue of observing an update to the preloaded pin list. Under the second interpretation, Site 1 would remain unpinned. The authors belief is that the issues that arise from either implementations are artifacts of the implementation and distribution of preloaded pins, rather than an issue intrinsic to this specification. That is, the correct answer is that the preloaded pin list should be updated for Site 1 - however that information is distributed between the site operator and the creator of the preloaded pin list. Are there concerns with this interpretation, or can we close out Issue 55? ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] Issue 56 - specify includeSubDomains for key pinning
With Key Pinning being split out from HTTP Strict Transport Security, one aspect that was lost was the includeSubDomains directive. This was raised as Issue 56 - http://trac.tools.ietf.org/wg/websec/trac/ticket/56 - against draft-03 draft-04 introduces the same directive, and with the same semantics, in Section 2.1.2 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.2 Is the added language acceptable? Are there any concerns with the validation/processing model that would prevent us from closing out this issue? ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] Issue 54 - Adding a report-only mode
As discussed during Atlanta, and as raised in http://trac.tools.ietf.org/wg/websec/trac/ticket/54 , there's a strong desire for a Content Security Policy-like report and report-only mode. The use of a report mode is not as an attack mitigation, but as a way of sites to be informed of misconfigurations. The use of a report-only mode is as a way to allow sites to experiment with and deploy a Pinning Policy effectively. Given that pinning is effectively ultimately dependent on client trust and PKI policies, it's important for site operators to be able to ensure their proposed pinning policy will work effectively. To that end, draft-04 has introduced the report-uri directive, Section 2.1.3, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.3 , which allows a site to specify a URL to direct reports, as described in Section 3 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-3 In addition, and in the spirit of CSP, we'd like to propose the addition of a Public-Key-Pins-Report-Only header, as described in Section 2.1 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1 - as a compliment to the Public-Key-Pins header. This header would follow the same syntax and semantics of the Public-Key-Pins header, with the exception of not actually enforcing the pins (as described Section 2.6). I'd like to solicit feedback and make sure that both the discussions from Atlanta and from the list have been accurately captured. Are there concerns with a Report-Only mode that have not been accurately captured? ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
