Subject: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 4 Mar 2013 16:57:20 -0800

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?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 05 Mar 2013 05:26:40 -0500

> or OS installation, not those installed by a user).

Sorry -- i wasn't in Atlanta, so i don't know the context or background
for this.  Can you explain more?

Consider the case where pre-loaded trust anchor ("trusted root
certificate authority") X certified my web server's EE certificate with
pubkey Y, and i published a pin on Y and my backup pubkey Z (but no pin
on X).

Are you saying that if i switch my server to use Z, and it is certified
by some non-(pre)loaded trust anchor (or it is self-signed), then Google
Chrome will not respect the pinning and the connection will fail?

	--dkg

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Mar 2013 11:17:55 +0000

> Chrome will not respect the pinning and the connection will fail?

Hi Daniel

Not respecting the pinning means that the connection will not fail.

Suppose the trust anchor store that comes with the OS on which Chrome is installed comes with two CAs: Verisign and StartCom. 

My computer also has another CA called BigCorpCA.

Suppose some website, such as tools.ietf.org has published a pin for Verisign.

Chrome will accept a certificate from Verisign, because it fits the pin
Chrome will accept a certificate from BigCorpCA, because it was added by the user (or by someone who has enough power over the user to install CAs on their computer)
Chrome will not accept a certificate from StartCom, because it goes against the PIN.

I can guess that the reason they do this is so that Chrome doesn't block on certificates from TLS proxies, that are becoming increasingly common.

Yoav (with no hats)

---

From: Tom Ritter <[email-masked]>
Date: Tue, 5 Mar 2013 21:54:58 -0500

> text sufficiently addresses the issue as originally raised?

I think it does, although I'm very curious about two points:

 - will implementations respect 'strict'?
 - who if any of the sites that have led the way on HSTS/pinning
(Google, Twitter) will enable strict

I guess we'll have to wait and see.

-tom