Public Key Pinning with Overrides breaks the presumptions of Secure Contexts

[noloader]

The latest editor's draft (11 December 2015) of Secure Contexts states the following:

As the web platform is extended to enable more useful and powerful applications, it becomes increasingly important to ensure that the features which enable those applications are enabled only in contexts which meet a minimum security level... (Introduction, § 1, ¶ 1)

The document goes on to say:

The most obvious of the requirements discussed here is that application code with access to sensitive or private data be delivered confidentially over authenticated channels that guarantee data integrity. (Introduction, § 1, ¶ 2)

My takeaway is Powerful Features, like Secure Contexts, require Authorizations, and they are implicitly tied to Authentication of the origin.

In the web/browser security model, the authentication is performed by a CA. When using Public Key Pinning Extension for HTTP (a.k.a. Public Key Pinning Extension for HTTP with Overrides), the various checks performed by a CA to provide entity authentication are disgorged. That is, the override discards the checks performed by the CA.

Discarding the checks means the assumption used to authorize access to the Power Features and Secure Contexts _do not_ exist. Additionally, the assurance levels (i.e., Domain Validated (DV), Organizational Validated (OV) and Extended Validated (EV)) no longer exists when an override is in effect.

---

The CA checks and subsequent use of the authentication information for authorizations seems to overlap with Java Applets, Code Signing and the Sandbox. That is, Java attempted to use Authentication for Authorizations. For insightful reading and the conclusion of the experiment, see Java’s Losing Security Legacy on Threatpost.

[jonathanKingston]

Could you clarify where the authentication in HPKP is skipped? My understanding is that authentication with CA's still happens despite it being pinned (This at least seems to be UAs implementation anyway).

Just to clarify: Powerful features and secure contexts are two sides of the same coin, the specification now refers to features that need secure contexts rather than powerful features.

On Tue, Jan 26, 2016 at 3:04 PM Jeffrey Walton notifications@github.com wrote:

The latest editor's draft (11 December 2015) of Secure Contexts https://w3c.github.io/webappsec-secure-contexts/ states the following:

As the web platform is extended to enable more useful and powerful applications, it becomes increasingly important to ensure that the features which enable those applications are enabled only in contexts which meet a minimum security level... (Introduction, § 1, ¶ 1)

The document goes on to say:

The most obvious of the requirements discussed here is that application code with access to sensitive or private data be delivered confidentially over authenticated channels that guarantee data integrity. (Introduction, § 1, ¶ 2)

My takeaway is Powerful Features, like Secure Contexts, require Authorizations, and they are implicitly tied to Authentication of the origin.

In the web/browser security model, the authentication is performed by a CA. When using Public Key Pinning Extension for HTTP http://tools.ietf.org/rfc/rfc7469.txt (a.k.a. Public Key Pinning Extension for HTTP with Overrides), the various checks performed by a CA to provide entity authentication are disgorged. That is, the override discards the checks performed by the CA.

Discarding the checks means the assumption used to authorize access to the Power Features and Secure Contexts do not exist. Additionally, the assurance levels (i.e., Domain Validated (DV), Organizational Validated (OV) and Extended Validated (EV)) no longer exists when an

override is in effect.

The CA checks and subsequent use of the authentication information for authorizations seems to overlap with Java Applets, Code Signing and the Sandbox. That is, Java attempted to use Authentication for Authorizations. For insightful reading and the conclusion of the experiment, see Java’s Losing Security Legacy https://threatpost.com/javas-losing-security-legacy/102176/ on Threatpost.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec-secure-contexts/issues/13.

[mikewest]

Pinned certificates need to chain to a root that the user agent trusts, either because it is a publicly trusted root, or because the user has installed it as a locally trusted root. I assume it's this last bit that you're objecting to, and that you'd prefer that a context no longer be considered secure if the user agent overrides a pinned certificate with a locally trusted root?

This seems outside the scope of the threat model which secure contexts are meant to address. That is, the user agent is empowered to decide what it trusts. If the user agent decides to trust the authenticity of servers asserted by a cert that chains to a locally trusted root, then it considers that context secure, full stop. Defining a "secure context" in any other terms doesn't make much sense to me.

[dveditz]

Can this issue be closed now? User Agents will only allow pinning if they are satisfied with the security of the certificate. In the absence of pinning the same host presenting the same certificate would be considered a "secure context".

[dveditz]

Oh, rather you're unhappy that there is a pin but the HPKP spec allows the UA to ignore it in certain cases. That would seem to be a problem for the HPKP spec, not the Secure Contexts one. At the point we've loaded the document content at all the UA is already satisfied it has connected securely to the origin. If the UA is wrong that's outside the scope of this spec.

[mikewest]

Closing this out.