Re: [websec] Comments on draft-ietf-websec-key-pinning-06

Trevor Perrin <trevp@trevp.net> Wed, 26 June 2013 00:13 UTC

Return-Path: <trevp@trevp.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 0460B21E80EC for <websec@ietfa.amsl.com>; Tue, 25 Jun 2013 17:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.48
X-Spam-Level:
X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
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 IYwNYFBd6H3T for <websec@ietfa.amsl.com>; Tue, 25 Jun 2013 17:13:52 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8721E80C9 for <websec@ietf.org>; Tue, 25 Jun 2013 17:13:51 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id n57so9902668wev.14 for <websec@ietf.org>; Tue, 25 Jun 2013 17:13:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=t2vha9/GdP8V0cvpSaqtviVIQyXRqL6Pblte/bcqwi4=; b=NloUGVcriDoEbsMlxiLFHmYESEEC5IGwzcCuYX3ozDba68cO+xbFilbPwI0T2ICzaz NG/g7DcbN1f9/vCpJfOxRmqWkIw0tmXziTj1fUiGhLt3L0LO32q3nvwulD3MmzirYrZV 3enPjmwt3lAX/B5vrg7IasOWF4aqhri8YtuIH4uL9EzGdVB4ZUgmqSHLxR2kp1SzH/kd Yfr2rPlfw7A/k90usSiZtSEpjFhd/Akbs54Y+EhtbUpYqMNEpgVnobqE5Hjt0SJ/PqiS UcqaNGzrL9is3YS/x4u2rDl5AlFF+GBVsgPFhrloAkmndNro5nVkJrdwrjX5/zANoiuW Cuvw==
MIME-Version: 1.0
X-Received: by 10.194.93.74 with SMTP id cs10mr1041130wjb.9.1372205629365; Tue, 25 Jun 2013 17:13:49 -0700 (PDT)
Received: by 10.216.212.9 with HTTP; Tue, 25 Jun 2013 17:13:49 -0700 (PDT)
X-Originating-IP: [166.137.212.54]
In-Reply-To: <CAOuvq20_KZPcBWyPgpGj=K5gy=1BGGRv11Zuxmcw_wBmzBhgUA@mail.gmail.com>
References: <8c03997da80b4e8da7100491011b8c12@BN1PR03MB039.namprd03.prod.outlook.com> <6F2FE5F2-D02C-4B09-A6CA-7C3B63722E34@checkpoint.com> <CAOuvq203V8LNjkimfd2m+aTX7-gKr=J62jmUqz-PDQEN6O9Lvg@mail.gmail.com> <CAOuvq20_KZPcBWyPgpGj=K5gy=1BGGRv11Zuxmcw_wBmzBhgUA@mail.gmail.com>
Date: Tue, 25 Jun 2013 17:13:49 -0700
Message-ID: <CAGZ8ZG1uHYxxh9q+z7767zW4=HWTa19EJGiu4oyERhTyM0KQBw@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Chris Palmer <palmer@google.com>
Content-Type: multipart/alternative; boundary="047d7bf0c86c18f20f04e00385fe"
X-Gm-Message-State: ALoCoQn5NXuzNjEFoPkJq11d5ajXWiR4Sjcli1Y3auU4Vpxdl7w0S/+4K6hydd1A+NiluZVSUvmk
Cc: "websec@ietf.org" <websec@ietf.org>, David Matson <dmatson@microsoft.com>
Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-06
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: Wed, 26 Jun 2013 00:13:57 -0000

On Mon, Jun 24, 2013 at 2:29 PM, Chris Palmer <palmer@google.com> wrote:

> If you haven't already, I'd urge everyone to take pcaps of a web
> session to their bank or to their web mail provider or whatever. I
> think you'll quickly see that even a large HPKP header, say 500 bytes,
> is not going to be the thing that makes web traffic bloated.
> (Sometimes, the certificate chains themselves outweigh the pins — and
> that traffic occurs before the crucial point of widening the TCP
> window! Whereas HTTP headers most likely occur afterward.)
>
> Also, at one point somebody raised an idea of saying you could pin to
> a set of keys — say, Symantec or StartCom's issuing certs — with a
> single directive. Something like:
>
>     Public-Key-Pins: max-age=...; pin-set: symantec; includeSubDomains
>

I like that!  It would be a lot easier to list your pin as
"symantec,comodo,godaddy" than the equivalent set of keys, particularly
since keys per CA change over time.




> There'd need to be some kind of registry for the names of sets, of
> course, which is complicated. And how do UAs learn of updates to the
> sets, and so on.


It seems like a registry IANA could maintain.  Any CA in a major root store
could register their name and a URL where they keep the list of keys
necessary to pin them.  Browser vendors will download these key lists (over
pinned HTTPS, of course) and push updates to browsers on some regular
basis.

Seems pretty workable...



> It's a nice idea that would improve on-the-wire size
> in bytes, and also enable web application providers to pin more
> easily. If there is demand, perhaps we could create such an extension
> to HPKP/TACK/et c. But I don't think it should be a blocker for this
> I-D.
>

TACK wouldn't do this, we're focused on self-chosen signing keys.  But it
would be a great v2 feature for HPKP, in my opinion...


Trevor