Return-Path: 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 ; 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 ; 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 ; Tue, 26 Aug 2014 17:53:28 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so12302467ykp.29 for ; 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: References: Date: Tue, 26 Aug 2014 17:53:27 -0700 Message-ID: From: Ryan Sleevi To: Trevor Perrin 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: "" , Eric Lawrence , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 00:53:30 -0000 --001a11c247e4189044050191d979 Content-Type: text/plain; charset=UTF-8 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" wrote: > On Tue, Aug 26, 2014 at 5:15 PM, Joseph Bonneau > 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 > --001a11c247e4189044050191d979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This seems like it would meaningfully necessitate changes to= the security and privacy considerations. In these cases, in specs and in c= ode, 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=C2=A0 wi= th 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&quo= t; <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<= br> >> (preference).
>
>
> My email wasn't very clear but I would also prefer this policy

I'd prefer this as well.=C2=A0 To be even clearer, I think the browser<= br> should treat PKP and PKP-RO headers independently.=C2=A0 I.e., the browser<= br> should maintain separate stores for PKP and PKP-RO data.=C2=A0 PKP headers<= br> only affect the PKP store, and PKP-RO headers only affect the PKP-RO
store.

(For example, PKP max-age=3D0 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
--001a11c247e4189044050191d979--