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 8E0FB21F8549 for <websec@ietfa.amsl.com>;
 Sat, 11 Aug 2012 13:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.407
X-Spam-Level: 
X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192,
 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 RwU1t1bMeT4z for
 <websec@ietfa.amsl.com>; Sat, 11 Aug 2012 13:38:10 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by
 ietfa.amsl.com (Postfix) with ESMTP id 94BDD21F8535 for <websec@ietf.org>;
 Sat, 11 Aug 2012 13:38:09 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com
 [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id
 q7BKbs7S003179; Sat, 11 Aug 2012 23:37:54 +0300
X-CheckPoint: {5026BF95-0-1B221DC2-4FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by
 il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi;
 Sat, 11 Aug 2012 23:37:54 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Chris Palmer <palmer@google.com>
Date: Sat, 11 Aug 2012 23:37:52 +0300
Thread-Topic: [saag] [websec] Pinning
Thread-Index: Ac14AS5KvY5+O10lTRm44RvftP/6Qg==
Message-ID: <24C52325-8B51-4DA0-B21D-DC72E184BB23@checkpoint.com>
References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com>
 <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com>
 <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org>
 <4FCF894B.8080002@gondrom.org>
 <CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com>
In-Reply-To: <CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Chris Evans <cevans@google.com>, IETF WebSec WG <websec@ietf.org>,
 Paul Hoffman <paul.hoffman@vpnc.org>, Sean Turner <turners@ieca.com>,
 Moxie Marlinspike <moxie@thoughtcrime.org>
Subject: Re: [websec] [saag]  Pinning
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: Sat, 11 Aug 2012 20:38:10 -0000

Hi Chris

I've removed SAAG from CC, trimmed most of your message, and re-arranged th=
e rest. Hope you don't mind=85

On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote:

> Additionally, HPKP and TACK might converge, more or less. I have plans
> to publish a new HPKP I-D that borrows some of TACK's pin activation
> and expiration ideas, for example.

<hat type=3D"chair">

Just as a reminder, HPKP is now a working group draft. As such, change cont=
rol is with the WG. Changes that change the rules for activation and expira=
tion should be proposed and discussed on the list first.=20

Having said that, we are pretty far from last call on key-pinning, so I thi=
nk it would be OK to publish a version -03 with such proposed changes, as l=
ong as those changes are clearly marked as not being the result of WG conse=
nsus.
</hat>

As an individual, I understand the limitations of the "spare public key" ap=
proach of the current HPKP. It's an administrative hassle to generate n spa=
re keys and keep them safe, and if you have n+1 key compromise events withi=
n the max-age time, your site is blocked. But it does have the big advantag=
e that the server side can be deployed *now* with no additional software. U=
ntil I see how those borrowed ideas can help with these issues, I prefer HP=
KP.

> So ultimately I do think we should decide on either HPKP or TACK, but
> that we should make that decision after there has been some real-world
> deployment experience with both (or, sadly, real-world non-deployment
> of one or both).

Well, there's WG deciding, and there's the market deciding. The IETF can pu=
blish both approaches (as either proposed standard or experimental) and the=
 one (if any) that the market prefers can later be upgraded to standard (or=
 it can stay at proposed anyway)

Yoav=