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

Yoav Nir <ynir@checkpoint.com> Tue, 05 March 2013 11:18 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1EC21F86BC for <websec@ietfa.amsl.com>; Tue, 5 Mar 2013 03:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju3VKyUfj3TT for <websec@ietfa.amsl.com>; Tue, 5 Mar 2013 03:18:01 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AA69221F86A1 for <websec@ietf.org>; Tue, 5 Mar 2013 03:18:00 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r25BHuSD004131; Tue, 5 Mar 2013 13:17:56 +0200
X-CheckPoint: {5135D40D-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Tue, 5 Mar 2013 13:17:56 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Thread-Topic: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors
Thread-Index: AQHOGTxpue254jfRf0afSx12uHk+Q5iWw9kAgAAOW4A=
Date: Tue, 5 Mar 2013 11:17:55 +0000
Message-ID: <76607A26-B747-4728-8133-AF57C5B709A9@checkpoint.com>
References: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> <5135C860.2080001@fifthhorseman.net>
In-Reply-To: <5135C860.2080001@fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.198]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4B1A4D0E49CC4D4E9F46416F47ACEDAD@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 11:18:05 -0000

On Mar 5, 2013, at 12:26 PM, Daniel Kahn Gillmor <dkg@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)