Re: [websec] Certificate Pinning via HSTS (.txt version)

=JeffH <Jeff.Hodges@KingsMountain.com> Mon, 12 September 2011 23:51 UTC

Return-Path: <Jeff.Hodges@KingsMountain.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 0745421F8E15 for <websec@ietfa.amsl.com>; Mon, 12 Sep 2011 16:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.121
X-Spam-Level:
X-Spam-Status: No, score=-99.121 tagged_above=-999 required=5 tests=[AWL=-1.640, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_48=0.6, RDNS_NONE=0.1, 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 JjaLXPPRLNF5 for <websec@ietfa.amsl.com>; Mon, 12 Sep 2011 16:51:23 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 58DBB21F8DD5 for <websec@ietf.org>; Mon, 12 Sep 2011 16:51:23 -0700 (PDT)
Received: (qmail 32116 invoked by uid 0); 12 Sep 2011 23:53:27 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 12 Sep 2011 23:53:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=VFVLu6bzbWBh7FGMxMJ0ReUFrLqmnhUMrcePBqp3l9c=; b=CekDJYHTEcA0ty+YwevGjPmm/xDBCoW2LrAU5f13GcaVPo0kzHNsOflfthUJpqlGoywuwocRgYSGwf8wggIbowTy99sT69mQfC9UZ/39kFwyQ83A9v06ARYMMYqtyJnb;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.218]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1R3GJa-00015L-VJ for websec@ietf.org; Mon, 12 Sep 2011 17:53:27 -0600
Message-ID: <4E6E9B77.1020802@KingsMountain.com>
Date: Mon, 12 Sep 2011 16:53:27 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: IETF WebSec WG <websec@ietf.org>
Content-Type: multipart/mixed; boundary="------------070305020800080208040402"
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [websec] Certificate Pinning via HSTS (.txt version)
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: Mon, 12 Sep 2011 23:51:25 -0000

 > 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.

This is great, thanks for posting this here.

I have various comments on it I'll try to get to in the next day or so.

During HSTS's gestation, various parties have discussed potential "LockCA" and 
"LockEV" directives ostensibly having similar semantics to what you've proposed 
here (see talk slides from last few websec sessions at IETF meetings). (though 
I think recent events pretty much obviate those nominal ideas because they'd 
relied on the resilience of one's CA and the CA infrastructure (oops))

Having a proposal such as this with a bunch of the background thinking (eg 
potential deployment downsides (aka "disasters")) noted down will help us on 
our way here.

I've taken the liberty of re-formatting the document in plain text (attached), 
which will better facilitate discussion hereabouts. A next step will be to 
re-format it as an Internet-Draft and get it submitted (I volunteer to help you 
out with that).

thanks again,

=JeffH