Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors
On 03/04/2013 07:57 PM, Ryan Sleevi wrote: 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). 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 signature.asc Description: OpenPGP digital signature ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors
On Mar 5, 2013, at 12:26 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 03/04/2013 07:57 PM, Ryan Sleevi wrote: 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). 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? 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) ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[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
