Re: [websec] Certificate Pinning via HSTS
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 14 September 2011 13:12 UTC
Return-Path: <dkg@fifthhorseman.net>
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 5A45821F8CBA for <websec@ietfa.amsl.com>; Wed, 14 Sep 2011 06:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level:
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
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 zpPaCWpzscZB for <websec@ietfa.amsl.com>; Wed, 14 Sep 2011 06:12:43 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E30BE21F8C4D for <websec@ietf.org>; Wed, 14 Sep 2011 06:12:41 -0700 (PDT)
Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 1F150F970; Wed, 14 Sep 2011 09:14:47 -0400 (EDT)
Message-ID: <4E70A8F8.80102@fifthhorseman.net>
Date: Wed, 14 Sep 2011 09:15:36 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0
MIME-Version: 1.0
To: Chris Palmer <palmer@google.com>
References: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com> <4E6F5056.800@fifthhorseman.net> <CAOuvq22E-OvU_53gf_go8Nf_jXX_=wbTf7rn2XEa+GAWHTU+7w@mail.gmail.com>
In-Reply-To: <CAOuvq22E-OvU_53gf_go8Nf_jXX_=wbTf7rn2XEa+GAWHTU+7w@mail.gmail.com>
X-Enigmail-Version: 1.2.1
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig3E071253BFE06FFBFE80D352"
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
Reply-To: IETF WebSec WG <websec@ietf.org>
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: Wed, 14 Sep 2011 13:12:44 -0000
On 09/13/2011 05:55 PM, Chris Palmer wrote: > On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor > <dkg@fifthhorseman.net> wrote: > >> From my perspective, i see no advantage to pinning any of the CAs -- if >> your EE is compromised, you're sunk. And since the mechanism provides a >> mechanism (and nice instructions, thanks) for transition to an emergency >> offline backup EE key+cert, that is all handled well. > > In the case of normal EE certificate expiration — as opposed to > compromise — if you are pinned to (say) an intermediary signer, you > can just get a fresh certificate from the same signer, deploy it, and > change nothing else. > > Conversely, if you had pinned to an EE, you'd need to follow a > procedure something like this near expiration time: > > 0. Generate the new cert. > 1. Change your pins directive to include the new and the old public > key fingerprints. > 2. Wait long enough for "most, surely?" of your users to have received > the new pins, or for their pins to expire by the normal maxAge means. > 3. Decommission the old EE cert and deploy the new. Actually, if your certificate policy requires key rotation at certificate expiry, you can generate key N+1 at any time (preferably early in the life of the cert corresponding to key N), and introduce the secondary pin at that point, without having gotten certificate N+1 yet. Then, as certificate N approaches expiration, get a certificate made from key N+1 -- your pin is already well-known. Generate key N+2 (stored safely offline someplace?), deploy key N+1, and update your pin list to be (N+1,N+2). There's no waiting required. And this approach dovetails nicely with your recommendations for backup resiliency as well. It still looks to me like pinning a CA does nothing more than give them the chance to hold you hostage at certificate renewal time, and to expose you to vulnerability should the CA itself be compromised. > You could, of course, also just re-use your old key pair and get it > re-signed, and no need to migrate keys as well as certs. In that case, > no problem. Yep; the only reason you'd need the more-complex approach above is if you require key rotation at certificate expiry. If all you care about is convenience and simplicity of operation, just get the existing key re-certified by any CA. In this case, there's still no need or advantage (and significant disadvantages) to pin to a CA instead of pinning to your EE. > Again, that's fine and one size does not fit all. Sure, one size does not fit all, but it looks like the document is (reasonably) trying to outline some common patterns of reasonable behavior to encourage best practices. I still don't see any best practice that involves pinning to a CA unless that CA is itself under the control of your own organization. I recommend that the draft make this explicit, to avoid encouraging system operators binding themselves even more tightly to a CA by misapplication of this mechanism. --dkg
- [websec] Certificate Pinning via HSTS Chris Palmer
- Re: [websec] Certificate Pinning via HSTS Richard L. Barnes
- Re: [websec] Certificate Pinning via HSTS SM
- Re: [websec] Certificate Pinning via HSTS =JeffH
- Re: [websec] Certificate Pinning via HSTS Richard L. Barnes
- Re: [websec] Certificate Pinning via HSTS Marsh Ray
- Re: [websec] Certificate Pinning via HSTS Yoav Nir
- Re: [websec] Certificate Pinning via HSTS Adam Langley
- Re: [websec] Certificate Pinning via HSTS James Nicoll
- Re: [websec] Certificate Pinning via HSTS Adam Langley
- Re: [websec] Certificate Pinning via HSTS Tobias Gondrom
- Re: [websec] Certificate Pinning via HSTS Tom Ritter
- Re: [websec] Certificate Pinning via HSTS Daniel Kahn Gillmor
- Re: [websec] Certificate Pinning via HSTS Philip Gladstone
- Re: [websec] Certificate Pinning via HSTS Chris Palmer
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker
- Re: [websec] Certificate Pinning via HSTS Chris Palmer
- Re: [websec] Certificate Pinning via HSTS Chris Palmer
- Re: [websec] Certificate Pinning via HSTS Daniel Kahn Gillmor
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker
- Re: [websec] Certificate Pinning via HSTS Daniel Kahn Gillmor
- Re: [websec] Certificate Pinning via HSTS Daniel Kahn Gillmor
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker
- Re: [websec] Certificate Pinning via HSTS Daniel Kahn Gillmor
- Re: [websec] Certificate Pinning via HSTS Phillip Hallam-Baker