IETF Logo Mail Archive

Re: [websec] draft-ietf-websec-key-pinning

Ryan Sleevi <sleevi@google.com> Wed, 27 August 2014 00:53 UTC

Return-Path: <sleevi@google.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214821A02DA for <websec@ietfa.amsl.com>; Tue, 26 Aug 2014 17:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyX9oSZH6Nhj for <websec@ietfa.amsl.com>; Tue, 26 Aug 2014 17:53:28 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C05D1A02CF for <websec@ietf.org>; Tue, 26 Aug 2014 17:53:28 -0700 (PDT)
Received: by mail-yk0-f170.google.com with SMTP id 9so12302467ykp.29 for <websec@ietf.org>; Tue, 26 Aug 2014 17:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MKVrjk6lGXs0srtGoQe9rBY0XjmNhABmSyBbK0yqWGk=; b=mZXsWJEKe0P9IVKv2rj9ie+Lb5K3xlVd0jvzfRgI9Hbp64oaH7UD4n65CngALaikgL 6TVS1Q6DMzG9z0fNe6E/f6hxuBuE9qYTRKcIdVAk4pEL5yHLHLw4m5jyKuZdCa1/Wumy UVV+yUJDKQmGrpj5wXEa1zPOY+5Bd9rMwUIZtG9ls2YxQBkgUuAAngyV9jnJ2FgKweE5 OSXyT3o4j0ji7f+ZjN1NvFaC7fE4yX0sIp/RcvlCNdtZ6/JQVgZPYpg2HY01x2kdnn3v voLcp2/2qp7cWIesFBuCA0dULoTL/pOMqI+W7SqdBXRlkJhv6h+Uz722x7iH8WUxB7v+ ZuLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MKVrjk6lGXs0srtGoQe9rBY0XjmNhABmSyBbK0yqWGk=; b=TeC8Ujr51ZzvFh1tpg3yXUFm34xcAepLCz7dcZIpgm2ikbHKzzqWNDKqB2DJ1XVHWk lqIywHE4WE/D3m/LG7YZ1veSlQ8ybfCWRCchY1Bjisy/dfZyau6q/7T+Yg3KvzD53lL9 mEJHulp9ahDIw/ZC9D/omO42IwzoeEswc2stdbJezf+ZwCvwzmCMK8aVfgnR5r48g7rn VZMkXEwiVadAaUZLmj2K7nxAqRsvjyxRPr5zvIldmoRfEp7fcAmil6ZrpcLDfpkCo5Fk aUFAiQ5Twh90t7nr25GvTf+RjGw4r7FeCYC0xO7mlBG3nFz9jwF5PI1Ijcd5Y9HTLJ/9 Emmg==
X-Gm-Message-State: ALoCoQleuqfGd0piYk9fJUHPN6NkEIieGI8K9v+dk+0SVI2/SS/MxV+l4LXSjmRe6wwXviUDalFE
MIME-Version: 1.0
X-Received: by 10.220.168.210 with SMTP id v18mr26315953vcy.3.1409100807697; Tue, 26 Aug 2014 17:53:27 -0700 (PDT)
Received: by 10.52.119.178 with HTTP; Tue, 26 Aug 2014 17:53:27 -0700 (PDT)
Received: by 10.52.119.178 with HTTP; Tue, 26 Aug 2014 17:53:27 -0700 (PDT)
In-Reply-To: <CAGZ8ZG3xoA1w1oEx9F8MuH1PARe5ALU9A1CEXqDXM-JSh_niGg@mail.gmail.com>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <CACvaWvYHAmpX0f9_m-sckhWz9tcyWA-sxVR4vP-A5UcAQmnYXA@mail.gmail.com> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <CA+cU71k-pLD315dzfd_c74QM51c7V2VQkZ26PiXUTqntmESD=A@mail.gmail.com> <CAOuvq20mZkScvPDKjsa1eZ6rdoHxf_+oF=gpaOcvkOTaYhyj6Q@mail.gmail.com> <CA+cU71mW47OvqRNTbw-H7u-F_k6hMv4xr0XcMYAS_V6eE8brwA@mail.gmail.com> <CAOuvq20C+T9Ejf_KUsfPRtUWL7ggCF0UWJZkGr5xGBEkERXeRQ@mail.gmail.com> <BAY169-DS45D73636AA204DEEABC876AEDC0@phx.gbl> <CAOuvq20kCKk=jcXsy_d8C-4Fn-f0zshP6YUPn5N8hsKt7KO7dw@mail.gmail.com> <CAGZ8ZG3KUPAbePp-_GCztj4RSLd8MuNo1iDz=ua+BEjQVzJc7Q@mail.gmail.com> <CA+cU71=A6vFXZrG8mcqj4uC-z2VdJfFOutqcq9MPTYs+uhpa9Q@mail.gmail.com> <CAOuvq22QgGVpsxrsZswqspiP-rgNE6B3vp_6bYDTE5-MrLZdVg@mail.gmail.com> <CA+cU71nN-=TjWZZovMUcTrXMF1gBcYFppnfnsaP7hKw+6AUCLQ@mail.gmail.com> <CAOe4Uim9ZC7MdY1tXhLWFwNxzxorh00bJ3PBsco_H-KxpYh-Dg@mail.gmail.com> <CAGZ8ZG3xoA1w1oEx9F8MuH1PARe5ALU9A1CEXqDXM-JSh_niGg@mail.gmail.com>
Date: Tue, 26 Aug 2014 17:53:27 -0700
Message-ID: <CACvaWvYjVXMsgCzL=mM+F8eS0hcjTqEaR7xYzti4LD4rdpbD1g@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Trevor Perrin <trevp@trevp.net>
Content-Type: multipart/alternative; boundary="001a11c247e4189044050191d979"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/BenW7Whw2vEB2bpuML7jmTKljhM
X-Mailman-Approved-At: Wed, 27 Aug 2014 03:31:47 -0700
Cc: "<websec@ietf.org>" <websec@ietf.org>, Eric Lawrence <ericlaw1979@hotmail.com>, draft-ietf-websec-key-pinning@tools.ietf.org
Subject: Re: [websec] draft-ietf-websec-key-pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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, 27 Aug 2014 00:53:30 -0000

This seems like it would meaningfully necessitate changes to the security
and privacy considerations. In these cases, in specs and in code, my
feeling is that less is more desirable, and I agree with Joe's remarks
about whether or not PKP-RO meets the goals.

Chairs, can you provide feedback on how to progress  with such significant
changes based on post-WGLC feedback: either the removal of or the changing
definition of PKP-RO.
On Aug 26, 2014 5:46 PM, "Trevor Perrin" <trevp@trevp.net> wrote:

> On Tue, Aug 26, 2014 at 5:15 PM, Joseph Bonneau <jbonneau@gmail.com>
> wrote:
> >>
> >> I'd like PKP-RO to be cached like PKP and applied the same way, absent
> >> the connection termination (preference). After I realized the
> >> includeSubdomains issue (concern), I want it even more for testing a
> >> deployment than I want it for my prior attack detection arguments
> >> (preference).
> >
> >
> > My email wasn't very clear but I would also prefer this policy
>
> I'd prefer this as well.  To be even clearer, I think the browser
> should treat PKP and PKP-RO headers independently.  I.e., the browser
> should maintain separate stores for PKP and PKP-RO data.  PKP headers
> only affect the PKP store, and PKP-RO headers only affect the PKP-RO
> store.
>
> (For example, PKP max-age=0 doesn't clear PKP-RO, and vice versa).
>
> A browser implementing this probably already has separate stores for
> HSTS and HPKP, so this is just adding a third for HPKP-RO, which seems
> reasonable to implement.
>
> Trevor
>

v2.23.0 | Report a Bug | By Email