Re: [websec] Certificate Pinning via HSTS

"Richard L. Barnes" <rbarnes@bbn.com> Tue, 13 September 2011 00:52 UTC

Return-Path: <rbarnes@bbn.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 C218D21F8DBC for <websec@ietfa.amsl.com>; Mon, 12 Sep 2011 17:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.604
X-Spam-Level:
X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 IrO1phAuGvCZ for <websec@ietfa.amsl.com>; Mon, 12 Sep 2011 17:52:15 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D26CF21F8D8A for <websec@ietf.org>; Mon, 12 Sep 2011 17:52:15 -0700 (PDT)
Received: from [128.89.253.131] (port=65335 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1R3HGR-000IWE-2F; Mon, 12 Sep 2011 20:54:15 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com>
Date: Mon, 12 Sep 2011 20:54:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <498A0E83-7C80-4226-9D69-7A7E93D8C929@bbn.com>
References: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
X-Mailer: Apple Mail (2.1084)
Cc: Chris Evans <cevans@google.com>, websec@ietf.org
Subject: Re: [websec] Certificate Pinning via HSTS
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, 13 Sep 2011 00:52:16 -0000

Hey Chris & Chris,

This seems like a useful near-term approach, but also probably something that might want to migrate to DANE over time.

Is there any particular reason you're using key fingerprints instead of cert fingerprints?  It seems like the latter might be slightly easier to implement, since you don't have to parse the cert.

--Richard



On Sep 12, 2011, at 5:56 PM, Chris Palmer wrote:

> Hi all,
> 
> Chris Evans and I work at Google on the Chrome security team. We have
> devised this specification for a new extension to Strict Transport
> Security to allow site operators to "pin" certificates: UAs will
> require that TLS connections be validated with at least one of the
> public keys identified in the new "pins" directive in the HSTS header.
> (Sites can pin to one or more public keys in end entity, subordinate
> CA, and/or root CA certificates, for flexibility and disaster
> recovery.)
> 
> We hope that this mechanism opens up the benefits of certificate
> pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior
> and certificate pins for sites, but the mechanism for doing this
> (email us!) does not scale.
> 
> We eagerly anticipate your comments, questions, concerns, et c. As you
> can see from the Ideas section, there are some unanswered questions
> about the behavior of UAs and hosts, and possible extensions to the
> policy.
> <CertificatePinningExtensionforHSTS.pdf>_______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec