From palmer@google.com Thu Feb 6 10:48:20 2014 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 AEC991A01DE for ; Thu, 6 Feb 2014 10:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 MyGmW_M7I2FX for ; Thu, 6 Feb 2014 10:48:19 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 01B391A0172 for ; Thu, 6 Feb 2014 10:48:18 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id x13so3843565qcv.19 for ; Thu, 06 Feb 2014 10:48:17 -0800 (PST) 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=PcWaBjQMF12mml8eJiJZKvs4hh5E31fTgi8OkMosNnI=; b=Ue51Jn2QXorWEqzWwagNfauVV9ctXg4wpLBuzP73XuNOMpTxx2bM9dT9Q8JWFTcixD 6HI/HjuIVt02e0Lb5T4Gq6QoOEV78f52qRmCSIztt1Sbsz0ukzgv7Wi9KPp+2Iq3IUBg Ou0eaT+t6QwzuR8TGdLikDs2gLHmondT1J5YlI/XhQKDyehSoJ5IpJxK1xuoC4IWlmVK I26GCe0Ku8BcLSaxqcJE4sCkV7O8a0JHrwfqOiXV8zAGzqrtYbslERl0tUITt/h8efla c2pi9MZgMurFvrqHYTTSwZE2r7bDropKeoXTFM/XHEY+73P8WogSLJiorLnuZ9KsuGZR uyeA== 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=PcWaBjQMF12mml8eJiJZKvs4hh5E31fTgi8OkMosNnI=; b=AtQ1EZnvW2BbzahsLy483Ewile5WCs63iWzKWnMYAUfvi0KAzNljfMKmuYPc7l3HQM T12KZ7gJu2XlHEWaT2wB9eYlWd0jImyCe9WKGDFRnaV14DCHXnm4Gs2TvoFSHh2XhiZe u9KPkAMGQffBu1piPhrls+P+mUrCe1VWVCKptbjVRasDtxyfbUfA4Dq4zDZ/6SJVdWGV R6pjbTEhkJPS95CspaBVFv4q4gGXQlmJCT1jDJXcqPSXDUMX8EGkiQSSQ2BwLOwIGzsC v0YGkVms6+nt1tLfK+bSfjJgTTAAXOqd+uN/8RQc+zYWATQm0DFFFK7g9nMQtg+PDeNK 7OnA== X-Gm-Message-State: ALoCoQltQ3/i4l5x1VBCaoxgCN0fxu66B2Q711M9ldQZhVpaB1B80S5UAfL/IEhWMhllsOxnR133+89bdDzqnuAVJvEGw1U9/06XTCj37pmqFB/78Le9BKIm2CLOL8g22Yg172UtCnV9pd9bAt+pCRH0L+kj7kr3dpDaie52WHVEP8vEj3AX5I4ibdRbUjcQ2x1RzFiqPn0N MIME-Version: 1.0 X-Received: by 10.224.127.202 with SMTP id h10mr14971439qas.23.1391712463661; Thu, 06 Feb 2014 10:47:43 -0800 (PST) Received: by 10.229.62.72 with HTTP; Thu, 6 Feb 2014 10:47:43 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Feb 2014 10:47:43 -0800 Message-ID: From: Chris Palmer To: Brian Smith Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: Storing unknown directives and effective pin date 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: Thu, 06 Feb 2014 18:48:20 -0000 On Mon, Dec 2, 2013 at 12:45 AM, Brian Smith wrote: > 1. Why must a UA store the effective pin date and the max-age > directive, instead of storing just the calculated expiration time = > effective pin date + max-age? I think that a UA can do a good enough > job at making sure it uses the latest available pin data without > needing to store the two separate items. I have updated the I-D to address this: https://code.google.com/p/key-pinning-draft/source/detail?spec=svnda615e6766479ac4ea69549ac56e4884b8169c07&r=da615e6766479ac4ea69549ac56e4884b8169c07 > 2. The requirement to store "future PKP header directives" seems to > mean that a UA must store directives that it doesn't understand, > presumably with the intention that it will process those stored > directives if/when it starts understanding them. This requirement is > unreasonable because it means that a UA may need to store huge HPKP > headers full of directives that it will never process. This limits our > options for efficiently encoding the stored information and also makes > it unnecessarily difficult for us to calculate storage costs for this > feature. In general, it seems to me that if it is safe for a UA to > ignore a directive when it is first received, then it will be safe for > the UA to ignore that directive until it receives a new HPKP header in > some future response. If this is not the case, then I recommend > changing the draft so that it would be safe. Regardless, I think the > draft should be changed so that implementations are not required to > store directives that they do not understand. Agreed. And that change is here: https://code.google.com/p/key-pinning-draft/source/detail?spec=svn68cf4ca5f25eeab48696561b999311b85cc6acb7&r=68cf4ca5f25eeab48696561b999311b85cc6acb7 I'll be pushing out a new I-D revision (10) in a few minutes with these and other changes (no more strict, no more SHA-1). From internet-drafts@ietf.org Thu Feb 6 11:01:08 2014 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 C46A41A00EA; Thu, 6 Feb 2014 11:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 FbNMgHugHVip; Thu, 6 Feb 2014 11:01:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3852A1A03E2; Thu, 6 Feb 2014 11:01:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 11:01:06 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-10.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:01:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Authors : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-10.txt Pages : 23 Date : 2014-02-06 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Fri Feb 7 01:39:49 2014 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 515891A05DF for ; Fri, 7 Feb 2014 01:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 icUEG2-UlO3C for ; Fri, 7 Feb 2014 01:39:47 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 611D71A01E5 for ; Fri, 7 Feb 2014 01:39:47 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s179di86003318 for ; Fri, 7 Feb 2014 11:39:44 +0200 X-CheckPoint: {52F4A2DF-13-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 11:39:44 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: WGLC for draft-ietf-websec-key-pinning-10 Thread-Index: AQHPI+iHfegE/LNl5EGrsl68Mjm8oQ== Date: Fri, 7 Feb 2014 09:39:43 +0000 Message-ID: <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> In-Reply-To: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.23] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <065D5BFDD8EBC34A97A23F602D528B25@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Fri, 07 Feb 2014 09:39:49 -0000 Thank you Chris, Chris and Ryan. This is to announce the beginning of a WGLC for this draft. Because a lot o= f the group members are busy preparing for London and getting those drafts = out by the deadline, we will extend the time allocated for this WGLC to thr= ee weeks, ending on February 28th. Please take this almost-final opportunity to review the draft and if you sp= ot a problem, send comments to the list. Thanks Tobias and Yoav On Feb 6, 2014, at 9:01 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Web Security Working Group of the IETF. >=20 > Title : Public Key Pinning Extension for HTTP > Authors : Chris Evans > Chris Palmer > Ryan Sleevi > Filename : draft-ietf-websec-key-pinning-10.txt > Pages : 23 > Date : 2014-02-06 >=20 > Abstract: > This memo describes an extension to the HTTP protocol allowing web > host operators to instruct user agents (UAs) to remember ("pin") the > hosts' cryptographic identities for a given period of time. During > that time, UAs will require that the host present a certificate chain > including at least one Subject Public Key Info structure whose > fingerprint matches one of the pinned fingerprints for that host. By > effectively reducing the number of authorities who can authenticate > the domain during the lifetime of the pin, pinning may reduce the > incidence of man-in-the-middle attacks due to compromised > Certification Authorities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From tom@ritter.vg Fri Feb 7 05:13:17 2014 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 6AA7E1A1E10 for ; Fri, 7 Feb 2014 05:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, SPF_PASS=-0.001] autolearn=no 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 yF8HEkw3FtaN for ; Fri, 7 Feb 2014 05:13:16 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 390311A03BF for ; Fri, 7 Feb 2014 05:13:16 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id rr13so3226072pbb.21 for ; Fri, 07 Feb 2014 05:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=40+6e1wCouGo8Fy/35iSToqlU7TJ578f7H/wcfoi3wo=; b=AFDxaC2GXFoml4ECXzLMCtA21zHRmy7mAJQDEJnhGR+b4qCEW/EGuzWH4pdSryX5sz eVmpYFXmu+Bp5/U7HdrEJxil6S5CSzFHHWnc+vmBIpaH3QxC1EoyvI0uMm52a+gMk0bf YDDyJASbteyVdY3SLk3txGd89/EeBzh7x5Tvo= 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:from:date :message-id:subject:to:cc:content-type; bh=40+6e1wCouGo8Fy/35iSToqlU7TJ578f7H/wcfoi3wo=; b=l228oDySULVGhyKtytOzX3PEUEG60SwG5eBMkZ98oAkhZESRT/qx+OchKveOXPVBOw pFM9Cm18qS4DcAUH1yob+6UU6PsVvfaoWmoP0XEKg88jdsjIwLJc0OqnnVfA4iRJ5PKN VqZUJPyGpCJv+J+0lmvDOpfyjlTxiH2pJHbGZqVP9TxozLu5jh6RLHd9t3A+DPNmtRvg epe4SeGtfJDjmctH0TotfmrCdA4eRBJtaJ2W5ZKMZbRx5XyAoGYYf/TElQcsMDu2Km1I dxb0h6yzU0zCRWR/eTQhm4Ja04NjJ3EUu/6lq5EF+jeI4CY0jW31tQMO/SWmADwLoowP oS5w== X-Gm-Message-State: ALoCoQkJA+YD7k3m7D8v5sn4SJxvYu6z1/Bf940K6eOTvuxbFrLpPLcUCuE5uNRqxxSBUarsS4lA X-Received: by 10.66.160.195 with SMTP id xm3mr7664296pab.93.1391778796075; Fri, 07 Feb 2014 05:13:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.169 with HTTP; Fri, 7 Feb 2014 05:12:56 -0800 (PST) In-Reply-To: <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> From: Tom Ritter Date: Fri, 7 Feb 2014 08:12:56 -0500 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Fri, 07 Feb 2014 13:13:17 -0000 " 5. If a PKP header field contains any directive(s) the UA does not recognize, the UA MUST ignore the those directives." Typo. -------- "If a Host sets both the Public-Key-Pins header and the Public-Key- Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins- Report-Only header." I thought we were following the CSP model, where you can enforce one policy, but test a second. -------- Figure 3 shows some example response header fields using the pins extension (folded for clarity). "d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=" "E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=" Public-Key-Pins: max-age=3000; pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; I think some base64 got added accidentally at the top. -------- "UAs MUST NOT heed http-equiv="Public-Key-Pins" attribute settings on elements [W3C.REC-html401-19991224] in received content." It might be pedantic, but perhaps 'or http-equiv="Public-Key-Pins-Report-Only"'? -------- UAs MUST recognize and "sha256". Typo -------- 'Pins' vs 'pins' Pedantry, but the noun pins is inconsistently capitalized through the document. -------- Reporting Pin Validation Failure The JSON report omits directives (such as max-age and includeSubDomains) that are likely to be relevant. It also omits superfluous certificates included in the chain that can be relevant. (In certificate validation testing, it's common to bypass it by including a superfluous chain that triggers a logic error. This would help diagnose these types of attacks.) -------- "The known-pins are the Pins that the UA has noted for the Known Pinned Host. They are provided as an array of strings with the syntax: known-pin = token "=" quoted-string Figure 6: Known Pin Syntax " I think this needs clarification (or fixing). 'Array of strings' + token=quoted-string. ["pin-sha256="base64==""] obviously doesn't work. An example JSON post would be cool. -------- Public-Key-Pins: pin-sha256="ABC..."; pin-sha256="DEF..."; includeSubDomains Figure 7: example.com Valid Pinning Header To make it 'valid' should it include max-age=123...? -------- "Here are two attack scenarios." You actually list four. (Two of which have empty top-level bullets.) -------- IANA Considerations This omits Public-Key-Pins-Report-Only -tom From palmer@google.com Fri Feb 7 17:22:41 2014 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 55F8F1AD8F5 for ; Fri, 7 Feb 2014 17:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 E4FjF6l10aj7 for ; Fri, 7 Feb 2014 17:22:39 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 480181A01E6 for ; Fri, 7 Feb 2014 17:22:39 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so6495529qae.27 for ; Fri, 07 Feb 2014 17:22:38 -0800 (PST) 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=N5u7AtllPoPpYIxVGvsd7g5xMlg85XxEuDLssY26gpg=; b=WGA9AngV9DerMBrxbsbeXh/hm4aBWvj1zscNUsFS7MsFm+DxEXMYejNAiSVyTpCkLC znfDaTTCy4a+UHcThHoYZ6OwLVX2ADr4jnVz+4Bfsc40/MGLkBXuFSVTVf3dTKKQK8F6 +zFbgRENxq7H426hyyjKGW0SytCTyVG+4iaeNt+DjtZ/G43hPC+S9XPRVHqwLiU4IHx/ GgDSCISEIX9o6GAMCcGzhtMzOWA2b1vAPFIoaCFqRWXlB3DXuVVnw+089Q1bfxtKuxnJ wHnSU9BxXpAk1CZyi5zyPQXRtNiv9lR9Dn1eMHIIGuP9hIBmYhEFwrnGWin/rszRflyT /RvA== 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=N5u7AtllPoPpYIxVGvsd7g5xMlg85XxEuDLssY26gpg=; b=eUVhLjMBsaL2CsCS4XVya1WjU5R+apDsBmm1///Ljp6afIKzRGJ6P25X4s08StGDuq 7wB13u6YP2OMPSsZegP834yiTmgDEM/d99dfhfOiXpQ91MTinKEHlikHv+J9mKbzvyMJ PrhO22uTB4XqQAkbo1VstVeqk/Aq9PcBSj+Coy+XLrVxz3M1W39bxmeJiO+Qpd8aYm57 2sDuP0Av8BnZHy1rPI0h06kjHoE/rjvpLVpf6W96LwjK2Qsl856znZSB9cCiXW4oUfzQ cP47BjevtMiuXd233beixxBDza5S7k+vJe7umuhNBodBSbpFoC8FVWU4DUymXCzSfeBZ E47w== X-Gm-Message-State: ALoCoQmOvGdrWKjZJd/Va/ULYwmcz4vjcaMktoJhgrG3Ip8boHTIaPntHdrbWiEoUYkOucBdjrxQXD0CWJR37dkQNv8YGRals1Nsz50zs05Wn6ZdT0wlek+FBVuvmvYGVlt9X+IAP8barwLaeyDdP6209xcVhAkXaed3mc/k9Pxe830HwegQs8L6hQuZ2DSnPKYCY9Z/DBSh MIME-Version: 1.0 X-Received: by 10.140.92.54 with SMTP id a51mr21498293qge.111.1391822558844; Fri, 07 Feb 2014 17:22:38 -0800 (PST) Received: by 10.229.62.72 with HTTP; Fri, 7 Feb 2014 17:22:38 -0800 (PST) In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Fri, 7 Feb 2014 17:22:38 -0800 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 01:22:41 -0000 Thank you, Tom! I have submitted revision 11 which I think/hope addresses all your points. And I added your name to the Thank You section. On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter wrote: > " 5. If a PKP header field contains any directive(s) the UA does not > recognize, the UA MUST ignore the those directives." > > Typo. > > -------- > > "If a Host sets both the Public-Key-Pins header and the Public-Key- > Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and > MUST note only the pins and directives given in the Public-Key-Pins- > Report-Only header." > > I thought we were following the CSP model, where you can enforce one > policy, but test a second. > > -------- > > Figure 3 shows some example response header fields using the pins > extension (folded for clarity). > > "d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=" > "E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=" > Public-Key-Pins: max-age=3000; > pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; > pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; > > I think some base64 got added accidentally at the top. > > -------- > > "UAs MUST NOT heed http-equiv="Public-Key-Pins" attribute settings on > elements [W3C.REC-html401-19991224] in received content." > > It might be pedantic, but perhaps 'or http-equiv="Public-Key-Pins-Report-Only"'? > > -------- > > UAs MUST recognize and "sha256". > > Typo > > -------- > > 'Pins' vs 'pins' > > Pedantry, but the noun pins is inconsistently capitalized through the document. > > -------- > > Reporting Pin Validation Failure > > The JSON report omits directives (such as max-age and > includeSubDomains) that are likely to be relevant. > It also omits superfluous certificates included in the chain that can > be relevant. (In certificate validation testing, it's common to bypass > it by including a superfluous chain that triggers a logic error. This > would help diagnose these types of attacks.) > > -------- > > "The known-pins are the Pins that the UA has noted for the Known > Pinned Host. They are provided as an array of strings with the > syntax: > > known-pin = token "=" quoted-string > Figure 6: Known Pin Syntax > " > > I think this needs clarification (or fixing). 'Array of strings' + > token=quoted-string. ["pin-sha256="base64==""] obviously doesn't > work. An example JSON post would be cool. > > -------- > > Public-Key-Pins: pin-sha256="ABC..."; pin-sha256="DEF..."; includeSubDomains > > Figure 7: example.com Valid Pinning Header > > To make it 'valid' should it include max-age=123...? > > -------- > > "Here are two attack scenarios." > > You actually list four. (Two of which have empty top-level bullets.) > > -------- > > IANA Considerations > > This omits Public-Key-Pins-Report-Only > > > > > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From internet-drafts@ietf.org Fri Feb 7 17:23:28 2014 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 C17A41A01E6; Fri, 7 Feb 2014 17:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lAkG7CrQz0OV; Fri, 7 Feb 2014 17:23:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E301A0582; Fri, 7 Feb 2014 17:23:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140208012325.7774.22126.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 17:23:25 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-11.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 01:23:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Authors : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-11.txt Pages : 24 Date : 2014-02-07 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From palmer@google.com Fri Feb 7 17:47:21 2014 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 BAFAF1AD7BE for ; Fri, 7 Feb 2014 17:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 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, RP_MATCHES_RCVD=-0.535, 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 YLLDgi5gt0I8 for ; Fri, 7 Feb 2014 17:47:20 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 602471AD6BF for ; Fri, 7 Feb 2014 17:47:20 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i7so5140192oag.15 for ; Fri, 07 Feb 2014 17:47:19 -0800 (PST) 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=6+2L19LLvet94dLs+nLiAPNZp5NZ4pIA/zRncgy9UEE=; b=go+InkhOinPlkQ3UJO7O8Pz02ewG36Hd9WgIi3soklAq2/oJx6iL5AnchWACmyqcdd EMR9PN/nB/WQTNfSaZgXAYJGavbNbPvgS61NnhIptDeM/29umd4ssQKERhYIFRL/7Djw 4LnY3IrxRdQJNyFP8cztKFeAPYIhOUOIuFxY2UAJIkWCeOcjX3102HcX0xNWi+4UVVZi 42pqr8aFL6AySl+P5CHfI2w7U2tQFEEusbnOFoEk6pXXYpwrCq+yuZKs7uWth1L9SRF+ B6Btx61B0m/ZAtRW2sHcsCk7MRVx4bMFTwQovuLYbGuVjrhToR6dc2pbAUXJ8C7OheTh ZZfw== 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=6+2L19LLvet94dLs+nLiAPNZp5NZ4pIA/zRncgy9UEE=; b=hbwcgWB6Qy06jtdAfsaREhJ9g0lBjc4gO9XEhflsixsrkhqebixNrvttFVkXQ36k9v 3LkQhRXcbYQy/sNtYRgMJ7w3qKL9fxvK3h8hMnmUpJfeGZdwp3XqFucVEDGAxoYe2XbH pOa0jHwlnkIzdlF9jVAndXTeirM4xxiyViRMTWMXLdgDNP7Q/0UnS6Ke4O+Lngfwvbr5 CnmPyv3v8W3GPxPB8ok+y8k3+T1AuEO6lf1gtL1zvd9x5K4fhia+Q0qjwJX0Iwv1gpsQ 7UOpHqpOxQCUr7ueu26BeRiD5c9ordzD9q5I018D8Y5J3aAUeotNz8cWCDwrsxwVThvi kQ9Q== X-Gm-Message-State: ALoCoQnl3uSycLnvwj7cak71aFX06EBySJCyzhqQyGjRMXi6IAMSJURb4y5BVRToi56V/rtym5zD3F41WZNUGKPluWpDhIY6sy7oVKZvOph7Od5tVSWQYuzCBks/2A6JaDd9OSJNZkD8nvQD02lZFSHp43vdLGkTxAUAqvF5MDNBZ/s2DYXsi1Ypb8QYjkkVWFfVeWh7xKQV MIME-Version: 1.0 X-Received: by 10.182.53.72 with SMTP id z8mr15522592obo.36.1391824039842; Fri, 07 Feb 2014 17:47:19 -0800 (PST) Received: by 10.182.79.194 with HTTP; Fri, 7 Feb 2014 17:47:19 -0800 (PST) In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Fri, 7 Feb 2014 17:47:19 -0800 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 01:47:22 -0000 Oops, I forgot one thing: On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter wrote: > "If a Host sets both the Public-Key-Pins header and the Public-Key- > Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and > MUST note only the pins and directives given in the Public-Key-Pins- > Report-Only header." > > I thought we were following the CSP model, where you can enforce one > policy, but test a second. Honestly, I think that's likely to be too complicated. I want to prioritize ease of deployment (which includes a simple-to-state policy like the above, and failing open when not unreasonably unsafe), and I'd like for the implementation not to get too much more complicated. From trevp@trevp.net Fri Feb 7 21:41:39 2014 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 269D41A0593 for ; Fri, 7 Feb 2014 21:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 6N71j4_ezFlZ for ; Fri, 7 Feb 2014 21:41:37 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF11A058E for ; Fri, 7 Feb 2014 21:41:37 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id p6so3267763vbe.6 for ; Fri, 07 Feb 2014 21:41:36 -0800 (PST) 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 :content-transfer-encoding; bh=FpqBsDdk7859A5t1HGnUTH7CjsWmTIgPuSKw0qeNohA=; b=Z57ZJNJgxO2dq9u6PmQE8LetXPgNQPMNdEAj8y2Muh3tNxEksTZgeP9i3+/xaZ2yqw ViH/FK4BdwlH5h657lNQvNvdpaxDbpBcLmakG7VyKz6m8AhhBo3gpSPWXiOCNyNoGGz5 HZlOP5dbdD9snSoWHRsw1+KvSefmfWrrY7EjFIzGn4tR44np1U43U8Ja37g5cUpk3W/F BbBWntk3ZYUorN3tiBUA/mjVwAxyih+EIcxNaWeK2h2V8Wf/AE6P8lll7YVCWL4ZgJGm 7kam5+sJOM/rYQNBJBXIn469us9kjiIVgCNBYv17vgh6JV3pwU4BMd8fOi84niAqrlNR xz9Q== X-Gm-Message-State: ALoCoQlr5Q6qyEmbyeGe/RJm9qypOtk3fXiEBue56tRaIpQSKpGkmaffixJh+XQvwQilhjdwdb5a MIME-Version: 1.0 X-Received: by 10.53.13.44 with SMTP id ev12mr11449341vdd.17.1391838096811; Fri, 07 Feb 2014 21:41:36 -0800 (PST) Received: by 10.220.107.140 with HTTP; Fri, 7 Feb 2014 21:41:36 -0800 (PST) X-Originating-IP: [208.181.190.104] In-Reply-To: <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Fri, 7 Feb 2014 21:41:36 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 05:41:39 -0000 On Fri, Feb 7, 2014 at 1:39 AM, Yoav Nir wrote: > Thank you Chris, Chris and Ryan. > > This is to announce the beginning of a WGLC for this draft. Because a lot= of the group members are busy preparing for London and getting those draft= s out by the deadline, we will extend the time allocated for this WGLC to t= hree weeks, ending on February 28th. > > Please take this almost-final opportunity to review the draft and if you = spot a problem, send comments to the list. Hi Yoav, You've been trying to rush through a "Last Call" since June. A new draft appeared hours ago. There were substantive open questions the last time we discussed this, and there have been substantive changes in the draft. It's going to take time for people to read the new draft, digest the changes, and discuss. Could you please give us this time and stop trying to force this? Trevor From ynir@checkpoint.com Sat Feb 8 07:00:29 2014 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 171EE1A0330 for ; Sat, 8 Feb 2014 07:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 HMLsYcRq3FWz for ; Sat, 8 Feb 2014 07:00:27 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E11A032A for ; Sat, 8 Feb 2014 07:00:27 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s18F0Awr007888; Sat, 8 Feb 2014 17:00:10 +0200 X-CheckPoint: {52F63F67-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sat, 8 Feb 2014 17:00:10 +0200 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] WGLC for draft-ietf-websec-key-pinning-10 Thread-Index: AQHPI+iHfegE/LNl5EGrsl68Mjm8oZqqt4QAgACcDQA= Date: Sat, 8 Feb 2014 15:00:09 +0000 Message-ID: <63C1AF57-D5F2-4681-80AF-CADD2EFD3C26@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.74] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1556F807C1459B4A9F2EE906339180E8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 15:00:29 -0000 On Feb 8, 2014, at 7:41 AM, Trevor Perrin wrote: > On Fri, Feb 7, 2014 at 1:39 AM, Yoav Nir wrote: >> Thank you Chris, Chris and Ryan. >>=20 >> This is to announce the beginning of a WGLC for this draft. Because a lo= t of the group members are busy preparing for London and getting those draf= ts out by the deadline, we will extend the time allocated for this WGLC to = three weeks, ending on February 28th. >>=20 >> Please take this almost-final opportunity to review the draft and if you= spot a problem, send comments to the list. >=20 > Hi Yoav, >=20 > You've been trying to rush through a "Last Call" since June. A new > draft appeared hours ago. There were substantive open questions the > last time we discussed this, and there have been substantive changes > in the draft. >=20 > It's going to take time for people to read the new draft, digest the > changes, and discuss. >=20 > Could you please give us this time and stop trying to force this? Hi Trevor. I don't think taking from June till now is "rushing". As you have said, the= re are substantive changes in the draft, and that is why we have allowed th= ree weeks rather than traditional two for this last call. We (Tobias, mysel= f and the authors) believe that the issue that have been raised have been a= ddressed in this version. If it turns out that there are new issues, on whi= ch we haven't yet reached consensus, we will discuss them, and have as many= more revisions as necessary.=20 In low-traffic mailing lists such as this one, there are participants who w= on't spend the time on reading and commenting until last call. In June we h= ad thought that all the issues were addressed, but new ones emerged only wh= en we started the WGLC. So we discussed more, and went through a few more r= evisions, and here we are. As always in the IETF, nothing leaves the workin= g group without consensus being called.=20 I believe that three weeks is plenty for reading, digesting and discussing.= =20 Regards, Yoav= From ynir@checkpoint.com Sat Feb 8 07:00:33 2014 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 62EDB1A032A for ; Sat, 8 Feb 2014 07:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 OOheUQ8gZGeM for ; Sat, 8 Feb 2014 07:00:31 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC01A034C for ; Sat, 8 Feb 2014 07:00:30 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s18F03Hp007780; Sat, 8 Feb 2014 17:00:04 +0200 X-CheckPoint: {52F63F60-B-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sat, 8 Feb 2014 17:00:03 +0200 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] WGLC for draft-ietf-websec-key-pinning-10 Thread-Index: AQHPI+iHfegE/LNl5EGrsl68Mjm8oZqqt4QAgACb+AA= Date: Sat, 8 Feb 2014 15:00:03 +0000 Message-ID: <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.74] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7907731F7639964984960A6D6A713E7A@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 15:00:33 -0000 On Feb 8, 2014, at 7:41 AM, Trevor Perrin wrote: > On Fri, Feb 7, 2014 at 1:39 AM, Yoav Nir wrote: >> Thank you Chris, Chris and Ryan. >>=20 >> This is to announce the beginning of a WGLC for this draft. Because a lo= t of the group members are busy preparing for London and getting those draf= ts out by the deadline, we will extend the time allocated for this WGLC to = three weeks, ending on February 28th. >>=20 >> Please take this almost-final opportunity to review the draft and if you= spot a problem, send comments to the list. >=20 > Hi Yoav, >=20 > You've been trying to rush through a "Last Call" since June. A new > draft appeared hours ago. There were substantive open questions the > last time we discussed this, and there have been substantive changes > in the draft. >=20 > It's going to take time for people to read the new draft, digest the > changes, and discuss. >=20 > Could you please give us this time and stop trying to force this? Hi Trevor. I don't think taking from June till now is "rushing". As you have said, the= re are substantive changes in the draft, and that is why we have allowed th= ree weeks rather than traditional two for this last call. We (Tobias, mysel= f and the authors) believe that the issue that have been raised have been a= ddressed in this version. If it turns out that there are new issues, on whi= ch we haven't yet reached consensus, we will discuss them, and have as many= more revisions as necessary.=20 In low-traffic mailing lists such as this one, there are participants who w= on't spend the time on reading and commenting until last call. In June we h= ad thought that all the issues were addressed, but new ones emerged only wh= en we started the WGLC. So we discussed more, and went through a few more r= evisions, and here we are. As always in the IETF, nothing leaves the workin= g group without consensus being called.=20 I believe that three weeks is plenty for reading, digesting and discussing.= =20 Regards, Yoav= From paul.hoffman@vpnc.org Sat Feb 8 08:37:01 2014 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 230A31A040A for ; Sat, 8 Feb 2014 08:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 f4ou8pIDQpH7 for ; Sat, 8 Feb 2014 08:36:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DA2541A03CC for ; Sat, 8 Feb 2014 08:36:59 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s18GawkU080739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Feb 2014 09:36:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Sat, 8 Feb 2014 08:36:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <18C68BFD-B923-4794-913C-508B22125863@vpnc.org> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> To: IETF WebSec WG X-Mailer: Apple Mail (2.1827) Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 16:37:01 -0000 On Feb 7, 2014, at 9:41 PM, Trevor Perrin wrote: > You've been trying to rush through a "Last Call" since June. A new > draft appeared hours ago. There were substantive open questions the > last time we discussed this, and there have been substantive changes > in the draft. >=20 > It's going to take time for people to read the new draft, digest the > changes, and discuss. >=20 > Could you please give us this time and stop trying to force this? 21 days for a WG Last Call is *long*, not short. One could easily argue = that the chairs were being too slow with that. --Paul Hoffman= From tom@ritter.vg Sat Feb 8 08:47:45 2014 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 AACCA1A02F8 for ; Sat, 8 Feb 2014 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 ep9vO2-J49ib for ; Sat, 8 Feb 2014 08:47:44 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1D13C1A01E8 for ; Sat, 8 Feb 2014 08:47:44 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so4457457pab.24 for ; Sat, 08 Feb 2014 08:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9OIiqzN1rHflBO+Fo7ptoXjeyMsPLZoG2I8LW+26s7Q=; b=Bq+0vxTOzpBwDaLfYmLd/MO67FtqwQ7drXAhuyq9QzVcvD4GjX/mpY8lGQjNKUC6Vh t2+iqcN2pJ/X1pqlUu6obZy1xRYvH3YnHnebK2tp5afEpfz0+XONuEvH6kno/t/Jfapv xen9erG+/6pJTGPVqAbH/DhUlV7MCgB2fQYPI= 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=9OIiqzN1rHflBO+Fo7ptoXjeyMsPLZoG2I8LW+26s7Q=; b=O1i0z/zJW/Qr1Zd2DsNg5iquJbVpmF1SZqtyPsf63E4VmXCGFzXKKq5b+yj2UhGJ/I NYvh6fBr0fcWaooTr4Uz82bz8F6SaOO/wslZvSK8QRbjd9CJ/fhY9N/5F7bbqMzgCKHT hXcasSnzmQb7Kna2bxpY9nBTQKTXjCmQZCw2KRznSdh5XT9vgal91rbQQqLiorGUXQhm oV5zRTwFOjm1elcuBL3hplG9BcdVhxI5wLJXO69MqfpRnkd+lESdBZDh5kRoiV20Ru+a qW/1R1MyY127uFo1YoCHFAfF9HlLoGDnSIN4UUSu4CuMn0/H3tL8ujT5VO2tmm1sLA0X o4vg== X-Gm-Message-State: ALoCoQnQxTJE3Q+ky9DMw+9G3IE/elVWfINnarl03NKyvp3PvSMADBbNJtKjK4j6scgJ0dWI8D20 MIME-Version: 1.0 X-Received: by 10.66.192.74 with SMTP id he10mr15107700pac.126.1391878064730; Sat, 08 Feb 2014 08:47:44 -0800 (PST) Received: by 10.68.211.169 with HTTP; Sat, 8 Feb 2014 08:47:44 -0800 (PST) Received: by 10.68.211.169 with HTTP; Sat, 8 Feb 2014 08:47:44 -0800 (PST) In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Sat, 8 Feb 2014 11:47:44 -0500 Message-ID: From: Tom Ritter To: Chris Palmer Content-Type: multipart/alternative; boundary=047d7bdc9ebc9e884e04f1e7dd5f Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 16:47:45 -0000 --047d7bdc9ebc9e884e04f1e7dd5f Content-Type: text/plain; charset=ISO-8859-1 On Feb 7, 2014 8:47 PM, "Chris Palmer" wrote: > > Oops, I forgot one thing: > > On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter wrote: > > > "If a Host sets both the Public-Key-Pins header and the Public-Key- > > Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and > > MUST note only the pins and directives given in the Public-Key-Pins- > > Report-Only header." > > > > I thought we were following the CSP model, where you can enforce one > > policy, but test a second. > > Honestly, I think that's likely to be too complicated. I want to > prioritize ease of deployment (which includes a simple-to-state policy > like the above, and failing open when not unreasonably unsafe), and > I'd like for the implementation not to get too much more complicated. I suppose. I think the extra implementation complication is in conditionally applying code rather than having to write additional code, which strike me as different, but you would know better than me. And that deployment would actually be made more confusing, not less, by having two analogous headers, named in the same pattern, that behave differently - I think that's likely to cause as much confusion as anything else. I imagine someone like Twitter, with its multiple pinned CAs, would have a really good use case for being able to apply and test two different policies. But, I also am anxious to get this out in the field - if anyone thinks similarly, they can speak up. -tom --047d7bdc9ebc9e884e04f1e7dd5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 7, 2014 8:47 PM, "Chris Palmer" <palmer@google.com> wrote:
>
> Oops, I forgot one thing:
>
> On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter <tom@ritter.vg> wrote:
>
> > "If a Host sets both the Public-Key-Pins header and the Publ= ic-Key-
> > =A0 =A0Pins-Report-Only header, the UA MUST NOT enforce Pin Valid= ation, and
> > =A0 =A0MUST note only the pins and directives given in the Public= -Key-Pins-
> > =A0 =A0Report-Only header."
> >
> > I thought we were following the CSP model, where you can enforce = one
> > policy, but test a second.
>
> Honestly, I think that's likely to be too complicated. I want to > prioritize ease of deployment (which includes a simple-to-state policy=
> like the above, and failing open when not unreasonably unsafe), and > I'd like for the implementation not to get too much more complicat= ed.

I suppose. I think the extra=A0 implementation complication = is in conditionally applying code rather than having to write additional co= de, which strike me as different, but you would know better than me.

And that deployment would actually be made more confusing, n= ot less, by=A0 having two analogous headers, named in the same pattern, tha= t behave differently - I think that's likely to cause as much confusion= as anything else.

I imagine someone like Twitter, with its multiple pinned CAs= , would have a really good use case for being able to apply and test two di= fferent policies.

But, I also am anxious to get this out in the field - if any= one thinks similarly, they can speak up.

-tom

--047d7bdc9ebc9e884e04f1e7dd5f-- From tobias.gondrom@gondrom.org Sat Feb 8 12:29:29 2014 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 257601A0609 for ; Sat, 8 Feb 2014 12:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Ci1o9t-J35hu for ; Sat, 8 Feb 2014 12:29:26 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6DC1A055F for ; Sat, 8 Feb 2014 12:29:26 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=I3QIUPFhMtNJMypy0y59kba2+OXQ+Y4yBw7JBOEHIdiSYijSVI1LMRgmMGHtWlORWrJBNjAuY8bRN9XC5ger1mcRp2oBUbcOgVdh0q7jrzbBjQi+8MqIPhdj0zgsR1FuZlsEbZC7SjFw50PGHgkMv8KqfLJ1rWB1jRhwp1CnYPY=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (2e40e8bc.skybroadband.com [46.64.232.188]) by www.gondrom.org (Postfix) with ESMTPSA id 682FA1539000F; Sat, 8 Feb 2014 21:29:24 +0100 (CET) Message-ID: <52F693A3.4030108@gondrom.org> Date: Sat, 08 Feb 2014 20:29:23 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ynir@checkpoint.com, trevp@trevp.net References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> In-Reply-To: <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 08 Feb 2014 20:29:29 -0000 On 08/02/14 15:00, Yoav Nir wrote: > On Feb 8, 2014, at 7:41 AM, Trevor Perrin wrote: > >> On Fri, Feb 7, 2014 at 1:39 AM, Yoav Nir wrote: >>> Thank you Chris, Chris and Ryan. >>> >>> This is to announce the beginning of a WGLC for this draft. Because a lot of the group members are busy preparing for London and getting those drafts out by the deadline, we will extend the time allocated for this WGLC to three weeks, ending on February 28th. >>> >>> Please take this almost-final opportunity to review the draft and if you spot a problem, send comments to the list. >> Hi Yoav, >> >> You've been trying to rush through a "Last Call" since June. A new >> draft appeared hours ago. There were substantive open questions the >> last time we discussed this, and there have been substantive changes >> in the draft. >> >> It's going to take time for people to read the new draft, digest the >> changes, and discuss. >> >> Could you please give us this time and stop trying to force this? > Hi Trevor. > > I don't think taking from June till now is "rushing". As you have said, there are substantive changes in the draft, and that is why we have allowed three weeks rather than traditional two for this last call. We (Tobias, myself and the authors) believe that the issue that have been raised have been addressed in this version. If it turns out that there are new issues, on which we haven't yet reached consensus, we will discuss them, and have as many more revisions as necessary. > > In low-traffic mailing lists such as this one, there are participants who won't spend the time on reading and commenting until last call. In June we had thought that all the issues were addressed, but new ones emerged only when we started the WGLC. So we discussed more, and went through a few more revisions, and here we are. As always in the IETF, nothing leaves the working group without consensus being called. > > I believe that three weeks is plenty for reading, digesting and discussing. > > Regards, > > Yoav Hi Trevor, I just wanted to add, that the call for WGLC has not been by decided by Yoav alone, but that as WG co-chairs we both discussed the appropriate timelines and are in full agreement on this. And as Paul pointed out by normal IETF standards a 3 week WGLC would normally be considered long. Best regards, Tobias Ps.: btw. if you think the draft still has major flaws or has not addressed adequately major flaws that have been pointed out earlier, I encourage you to post this now during the WGLC. From trevp@trevp.net Sat Feb 8 16:53:12 2014 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 E211B1A065C for ; Sat, 8 Feb 2014 16:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 9AlBnGR1nymr for ; Sat, 8 Feb 2014 16:53:10 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF41A0520 for ; Sat, 8 Feb 2014 16:53:10 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id cz12so4022544veb.29 for ; Sat, 08 Feb 2014 16:53:10 -0800 (PST) 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 :content-transfer-encoding; bh=F8ayn9kytVUCtVIsS5AljDtMgd+JuVwpg4UQFlyhDI8=; b=hUnlRVR3La0+8GGAJ6+BW+P7ENYvEf1OJLPdtwzpUMx0A8sOSyvRoVCwDiS+9Isg8y lqdESnurZAOd/BXKfsgRCiamVK6c4eqSEifazF2UY6o909pU1H2+/SezvLdZxSU8kV5X l03UVocfu5hd53d9cuPtZJMx0bPU6u7KnglaSQrp7dDWwrP7nzcgwaMC4B0a7N37wFOU W8ye7NlF4JdQwkoXWxIagWXRFzS33lgJSHZ1JcM8Nw6VaU54siNuzKUOT1jNwM+C/a5b JD8MVlF8sf7/KIbuzhUVxbZ5v0YSCuCMLrurqfJ4C5yY4ifcQV6ZN6fd0kLQZnG0B0H4 rHog== X-Gm-Message-State: ALoCoQnz64512M2wP4UAPlKlTzag+G4akn5h3kA+ok3ckuYjpV2K3p3LmlpA3bU5uv9/0GhVA0i+ MIME-Version: 1.0 X-Received: by 10.52.189.33 with SMTP id gf1mr613625vdc.26.1391907190291; Sat, 08 Feb 2014 16:53:10 -0800 (PST) Received: by 10.220.107.140 with HTTP; Sat, 8 Feb 2014 16:53:10 -0800 (PST) X-Originating-IP: [208.181.190.104] In-Reply-To: <52F693A3.4030108@gondrom.org> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> <52F693A3.4030108@gondrom.org> Date: Sat, 8 Feb 2014 16:53:10 -0800 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sun, 09 Feb 2014 00:53:13 -0000 I had ~20 comments on the last draft [1], which were issues I first brought up in July and which the chairs have apparently decided to ignore. Brian Smith had several comments. There's still an open issue in the tracker which I've brought up a few times. List volume is low because we've been spent most of the last several months waiting for a new draft, not because we're out of things to discuss. It would be helpful if the chairs were tracking open issues and promoting discussion to make sure they're resolved via on-list consensus, instead of just trying to force a document through. Trevor http://www.ietf.org/mail-archive/web/websec/current/msg01956.html On Sat, Feb 8, 2014 at 12:29 PM, Tobias Gondrom wrote: > On 08/02/14 15:00, Yoav Nir wrote: >> On Feb 8, 2014, at 7:41 AM, Trevor Perrin wrote: >> >>> On Fri, Feb 7, 2014 at 1:39 AM, Yoav Nir wrote: >>>> Thank you Chris, Chris and Ryan. >>>> >>>> This is to announce the beginning of a WGLC for this draft. Because a = lot of the group members are busy preparing for London and getting those dr= afts out by the deadline, we will extend the time allocated for this WGLC t= o three weeks, ending on February 28th. >>>> >>>> Please take this almost-final opportunity to review the draft and if y= ou spot a problem, send comments to the list. >>> Hi Yoav, >>> >>> You've been trying to rush through a "Last Call" since June. A new >>> draft appeared hours ago. There were substantive open questions the >>> last time we discussed this, and there have been substantive changes >>> in the draft. >>> >>> It's going to take time for people to read the new draft, digest the >>> changes, and discuss. >>> >>> Could you please give us this time and stop trying to force this? >> Hi Trevor. >> >> I don't think taking from June till now is "rushing". As you have said, = there are substantive changes in the draft, and that is why we have allowed= three weeks rather than traditional two for this last call. We (Tobias, my= self and the authors) believe that the issue that have been raised have bee= n addressed in this version. If it turns out that there are new issues, on = which we haven't yet reached consensus, we will discuss them, and have as m= any more revisions as necessary. >> >> In low-traffic mailing lists such as this one, there are participants wh= o won't spend the time on reading and commenting until last call. In June w= e had thought that all the issues were addressed, but new ones emerged only= when we started the WGLC. So we discussed more, and went through a few mor= e revisions, and here we are. As always in the IETF, nothing leaves the wor= king group without consensus being called. >> >> I believe that three weeks is plenty for reading, digesting and discussi= ng. >> >> Regards, >> >> Yoav > > > Hi Trevor, > > I just wanted to add, that the call for WGLC has not been by decided by > Yoav alone, but that as WG co-chairs we both discussed the appropriate > timelines and are in full agreement on this. > > And as Paul pointed out by normal IETF standards a 3 week WGLC would > normally be considered long. > > Best regards, Tobias > > > Ps.: btw. if you think the draft still has major flaws or has not > addressed adequately major flaws that have been pointed out earlier, I > encourage you to post this now during the WGLC. > > From ynir@checkpoint.com Sat Feb 8 21:02:07 2014 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 ECC4F1A0347 for ; Sat, 8 Feb 2014 21:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 EUnQbWsR2o5K for ; Sat, 8 Feb 2014 21:02:05 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B3C321A0695 for ; Sat, 8 Feb 2014 21:02:04 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s19520HA008227; Sun, 9 Feb 2014 07:02:00 +0200 X-CheckPoint: {52F704AC-C-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sun, 9 Feb 2014 07:02:00 +0200 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] WGLC for draft-ietf-websec-key-pinning-10 Thread-Index: AQHPI+iHfegE/LNl5EGrsl68Mjm8oZqqt4QAgACb+ACAAFwTgIAASbMAgABFhYA= Date: Sun, 9 Feb 2014 05:02:00 +0000 Message-ID: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> <52F693A3.4030108@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.192] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sun, 09 Feb 2014 05:02:07 -0000 Hi Trevor The issue on the tracker is about the interaction of dynamic pins with pre-= loaded pins. The authors have written section 2.7 to address this.=20 So let's bring back your points: * Preloaded pin stores will be periodically updated, which means browsers will need to handle "backdated" pins, i.e. pins that are received *after* other HPKP observations but have an "Effective Pin Date" which is earlier. To handle these in accordance with 2.7 requires browsers to remember "un-pinning" observations (expired pins, max-age=3D0, or nonexistent HPKP headers). This is sufficiently complex that the spec needs some treatment of it. * 2.7 mandates that the most recent observation from any source MUST take priority. Browsers would not be allowed to implement other priority rules, such as prioritizing one source over another, prioritizing fail-open or fail-closed behavior, or anything else. I believe this is overly restrictive. Some browsers might prefer different policies, e.g. simpler policies that don't require tracking "un-pinning" data. Section 2.7 is pasted below my sig. Yoav 2.7. Interactions With Preloaded Pin Lists UAs MAY choose to implement additional sources of pinning information, such as through built-in lists of pinning information. Such UAs SHOULD allow users to override such additional sources, including disabling them from consideration. UAs that support additional sources of pinning information MUST use the most recently observed pinning information when performing Pin Validation for a host. The most recently observed pinning information is determined based upon the most recent Effective Pin Date, as described in Section 2.3.2 . If the result of noting a Valid Pinning Header is to disable pinning for the host, such as through supplying a max-age directive with a value of 0, UAs MUST allow this new information to override any other pinning data. That is, a host must be able to un-pin itself, even in the presence of built-in Pins. Example: A UA may ship with a pre-configured list of Pins that are collected from past observations of Valid Pinning Headers supplied by hosts. In such a solution, the pre-configured list should track when the Valid Pinning Header was last observed, in order to permit site operators to later update the value by supplying a new Valid Pinning Header. Updates to such a pre-configured list should not update the Effective Pin Dates for each host unless the list vendor has actually observed a more recent header. This is to prevent situations where updating the Effective Pin Date on a pre-configured list of Pins may effectively extend the max-age beyond the site operator's stated policy. Example: A UA may ship with a pre-configured list of Pins that are collected through out-of-band means, such as direct contact with the site operator. In such a solution, the site operator accepts responsibility for keeping the configured Valid Pinning Header in sync with the vendor's list, allowing the UA vendor to have each update to the list be treated as as an update of the Effective Pin Date. From ynir@checkpoint.com Sat Feb 8 23:24:46 2014 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 91FAC1A069F for ; Sat, 8 Feb 2014 23:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 VvL1NG2cmZqE for ; Sat, 8 Feb 2014 23:24:44 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D44E11A05A8 for ; Sat, 8 Feb 2014 23:24:43 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s197Ocsr027484; Sun, 9 Feb 2014 09:24:38 +0200 X-CheckPoint: {52F72619-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sun, 9 Feb 2014 09:24:38 +0200 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] WGLC for draft-ietf-websec-key-pinning-10 Thread-Index: AQHPI+iHfegE/LNl5EGrsl68Mjm8oZqqt4QAgACb+ACAAFwTgIAASbMAgABFhYCAACfTgA== Date: Sun, 9 Feb 2014 07:24:38 +0000 Message-ID: <4C50494B-55D9-4621-9D78-C69B0AA5FAE3@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> <52F693A3.4030108@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.72] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19B5B658B8FAA44ABDBC9DC4CB07F3C7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sun, 09 Feb 2014 07:24:46 -0000 [Replying to myself, but with no hats on] IMO the current text is fine. Regarding the first point, it creates a burde= n for the browser maker, but only if they update their pre-loaded pin list = by observation. If it's created by OOB means as described in the second exa= mple, the burden is on the site operators, and they are likely to unpin in = both places at the same time. I think this also goes to your second point.= =20 I think in a future where HPKP is supported in most browsers, pre-loaded li= sts will contain very few entries - perhaps the big content sites and a few= banks, maybe Paypal. I expect that most site operators would be happier to= pin sites by themselves with an HPKP header rather than interact with all = browser vendors.=20 Yoav On Feb 9, 2014, at 7:02 AM, Yoav Nir wrote: > Hi Trevor >=20 > The issue on the tracker is about the interaction of dynamic pins with pr= e-loaded pins. The authors have written section 2.7 to address this.=20 >=20 > So let's bring back your points: >=20 > * Preloaded pin stores will be periodically updated, which means > browsers will need to handle "backdated" pins, i.e. pins that are > received *after* other HPKP observations but have an "Effective Pin > Date" which is earlier. To handle these in accordance with 2.7 > requires browsers to remember "un-pinning" observations (expired pins, > max-age=3D0, or nonexistent HPKP headers). This is sufficiently complex > that the spec needs some treatment of it. >=20 > * 2.7 mandates that the most recent observation from any source MUST > take priority. Browsers would not be allowed to implement other > priority rules, such as prioritizing one source over another, > prioritizing fail-open or fail-closed behavior, or anything else. I > believe this is overly restrictive. Some browsers might prefer > different policies, e.g. simpler policies that don't require tracking > "un-pinning" data. >=20 > Section 2.7 is pasted below my sig. >=20 >=20 > Yoav >=20 >=20 > 2.7. Interactions With Preloaded Pin Lists >=20 >=20 > UAs MAY choose to implement additional sources of pinning > information, such as through built-in lists of pinning information. > Such UAs SHOULD allow users to override such additional sources, > including disabling them from consideration. >=20 > UAs that support additional sources of pinning information MUST use > the most recently observed pinning information when performing Pin > Validation for a host. The most recently observed pinning > information is determined based upon the most recent Effective Pin > Date, as described in Section 2.3.2 > . >=20 > If the result of noting a Valid Pinning Header is to disable pinning > for the host, such as through supplying a max-age directive with a > value of 0, UAs MUST allow this new information to override any other > pinning data. That is, a host must be able to un-pin itself, even in > the presence of built-in Pins. >=20 > Example: A UA may ship with a pre-configured list of Pins that are > collected from past observations of Valid Pinning Headers supplied by > hosts. In such a solution, the pre-configured list should track when > the Valid Pinning Header was last observed, in order to permit site > operators to later update the value by supplying a new Valid Pinning > Header. Updates to such a pre-configured list should not update the > Effective Pin Dates for each host unless the list vendor has actually > observed a more recent header. This is to prevent situations where > updating the Effective Pin Date on a pre-configured list of Pins may > effectively extend the max-age beyond the site operator's stated > policy. >=20 > Example: A UA may ship with a pre-configured list of Pins that are > collected through out-of-band means, such as direct contact with the > site operator. In such a solution, the site operator accepts > responsibility for keeping the configured Valid Pinning Header in > sync with the vendor's list, allowing the UA vendor to have each > update to the list be treated as as an update of the Effective Pin > Date. >=20 >=20 >=20 From tobias.gondrom@gondrom.org Sun Feb 9 02:21:46 2014 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 C29701A06D3 for ; Sun, 9 Feb 2014 02:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 k17HRnQcf4jj for ; Sun, 9 Feb 2014 02:21:44 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id A8A751A06D2 for ; Sun, 9 Feb 2014 02:21:43 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gkU03nG9eSY4Kfz1dMOhDFKVHPqVfjcTtHwrXtGfZLk38JAEMct/wxNLJioEie67Qx2zfBRGTtf1I6dpZdP6FGQNS76flfPwttQWoVgggg9Br0GyfHFDdZDlAmc8llGRbSKloVf0FAcQVUmW8esl4T1jQSrD0j2U9HgoxFwJSuc=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (2e40e8bc.skybroadband.com [46.64.232.188]) by www.gondrom.org (Postfix) with ESMTPSA id A4B801539000F; Sun, 9 Feb 2014 11:21:42 +0100 (CET) Message-ID: <52F756B5.7080809@gondrom.org> Date: Sun, 09 Feb 2014 10:21:41 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: trevp@trevp.net References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> <52F693A3.4030108@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sun, 09 Feb 2014 10:21:47 -0000 Hi Trevor, I had no intention to ignore issues being raised. I was rather under the impression they had been addressed via the issue tracker and in the new version of the draft. One purpose of the WGLC is in fact to verify that all issues have been resolved and weed out any remaining problems. We have no intention of "forcing through" a document. And I fully recognise the fact that new revisions of the draft have regrettably been coming rather slow and that this can have contributed to low volume on the mailing-list, waiting for the revised text. Maybe to approach every issue in a structured approach in order to avoid missing any open issues: In my understanding all topics you and others posted have been mapped to issues in the tracker. Are we missing something there? If so or if you see new issues, please re-raise them on the mailing-list and please feel free to post issues in the tracker. We use the tracker to track open issues and to close them when they have been discussed. When you disagree with the closing of an issue it is good to raise your objections when that happens to make sure the WG understands your opinion and concerns and can discuss the problem accordingly. All the best, Tobias (co-chair of websec) On 09/02/14 00:53, Trevor Perrin wrote: > I had ~20 comments on the last draft [1], which were issues I first > brought up in July and which the chairs have apparently decided to > ignore. Brian Smith had several comments. There's still an open > issue in the tracker which I've brought up a few times. > > List volume is low because we've been spent most of the last several > months waiting for a new draft, not because we're out of things to > discuss. > > It would be helpful if the chairs were tracking open issues and > promoting discussion to make sure they're resolved via on-list > consensus, instead of just trying to force a document through. > > > Trevor > > > http://www.ietf.org/mail-archive/web/websec/current/msg01956.html > > > On Sat, Feb 8, 2014 at 12:29 PM, Tobias Gondrom > wrote: >> On 08/02/14 15:00, Yoav Nir wrote: >>> On Feb 8, 2014, at 7:41 AM, Trevor Perrin wrote: >>> >>>> On Fri, Feb 7, 2014 at 1:39 AM, Yoav Nir wrote: >>>>> Thank you Chris, Chris and Ryan. >>>>> >>>>> This is to announce the beginning of a WGLC for this draft. Because a lot of the group members are busy preparing for London and getting those drafts out by the deadline, we will extend the time allocated for this WGLC to three weeks, ending on February 28th. >>>>> >>>>> Please take this almost-final opportunity to review the draft and if you spot a problem, send comments to the list. >>>> Hi Yoav, >>>> >>>> You've been trying to rush through a "Last Call" since June. A new >>>> draft appeared hours ago. There were substantive open questions the >>>> last time we discussed this, and there have been substantive changes >>>> in the draft. >>>> >>>> It's going to take time for people to read the new draft, digest the >>>> changes, and discuss. >>>> >>>> Could you please give us this time and stop trying to force this? >>> Hi Trevor. >>> >>> I don't think taking from June till now is "rushing". As you have said, there are substantive changes in the draft, and that is why we have allowed three weeks rather than traditional two for this last call. We (Tobias, myself and the authors) believe that the issue that have been raised have been addressed in this version. If it turns out that there are new issues, on which we haven't yet reached consensus, we will discuss them, and have as many more revisions as necessary. >>> >>> In low-traffic mailing lists such as this one, there are participants who won't spend the time on reading and commenting until last call. In June we had thought that all the issues were addressed, but new ones emerged only when we started the WGLC. So we discussed more, and went through a few more revisions, and here we are. As always in the IETF, nothing leaves the working group without consensus being called. >>> >>> I believe that three weeks is plenty for reading, digesting and discussing. >>> >>> Regards, >>> >>> Yoav >> >> Hi Trevor, >> >> I just wanted to add, that the call for WGLC has not been by decided by >> Yoav alone, but that as WG co-chairs we both discussed the appropriate >> timelines and are in full agreement on this. >> >> And as Paul pointed out by normal IETF standards a 3 week WGLC would >> normally be considered long. >> >> Best regards, Tobias >> >> >> Ps.: btw. if you think the draft still has major flaws or has not >> addressed adequately major flaws that have been pointed out earlier, I >> encourage you to post this now during the WGLC. >> >> From synp71@live.com Wed Feb 12 04:26:50 2014 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 3C43D1A0914 for ; Wed, 12 Feb 2014 04:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 rlYT5P9Olb5w for ; Wed, 12 Feb 2014 04:26:48 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7644A1A0974 for ; Wed, 12 Feb 2014 04:26:48 -0800 (PST) Received: from BLU0-SMTP157 ([65.55.116.7]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Feb 2014 04:26:48 -0800 X-TMN: [VUz85QJwoPZKKAocA5wBsCOqLhRsogXf] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([194.29.32.131]) by BLU0-SMTP157.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Feb 2014 04:26:45 -0800 Date: Wed, 12 Feb 2014 14:26:41 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yoav Nir , IETF WebSec WG References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> In-Reply-To: <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000700010001090305000601" X-OriginalArrivalTime: 12 Feb 2014 12:26:45.0470 (UTC) FILETIME=[B17067E0:01CF27ED] Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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, 12 Feb 2014 12:26:50 -0000 --------------ms000700010001090305000601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 7/2/14 11:39 AM, Yoav Nir wrote: > Thank you Chris, Chris and Ryan. > > This is to announce the beginning of a WGLC for this draft. Because a l= ot of the group members are busy preparing for London and getting those d= rafts out by the deadline, we will extend the time allocated for this WGL= C to three weeks, ending on February 28th. > > Please take this almost-final opportunity to review the draft and if yo= u spot a problem, send comments to the list. > > Thanks > > Tobias and Yoav Some comments of my own. No hats Section 1, first sentence begins with "We propose a new...". Our target=20 is called "proposed standard", but I think it would be better to say "We = define a new HTTP header..." --------- Fourth paragraph in section 2.1.3 is kind of clunky: OLD "When used in the Public-Key-Pins header, the presence of a report-uri=20 directive indicates to the UA that the UA MUST enforce Pin Validation,=20 and the UA SHOULD also, in the event of Pin Validation failure, POST a=20 report to the report-uri." The presence of the report-uri directive has nothing to do with the UA=20 having to enforce pin validation. That is required by any PKP header.=20 How about rewriting this as: NEW "When used in the Public-Key-Pins header, the presence of a report-uri=20 directive indicates to the UA that it SHOULD also, in the event of Pin=20 Validation failure, POST a report to the report-uri." --- ------ Section 2.5. Section 2.4 says that future versions may add new algorithms. So we=20 should be prepared for new algorithms. Section 2.5 says "For forward=20 compatibility, the UA MUST ignore any unrecognized Public-Key-Pins=20 header directives, while still processing those directives it does=20 recognize." So suppose the UA got the following header: Public-Key-Pins: max-age=3D2592000; pin-sha4-256=3D"E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=3D"; pin-sha4-256=3D"LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=3D" Not having support for SHA4, it can't validate or use these pins. That=20 is fine when the server keys are not yet pinned. Now suppose that the=20 server is pinned (because previously it expressed HPKP with a SHA2-256.=20 Does the UA (a) ignore it, keeping the old pin, or (b) treat this as=20 unpinning? Either way, where does it say so? Thanks Yoav --------------ms000700010001090305000601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTQwMjEyMTIyNjQxWjAjBgkqhkiG9w0BCQQxFgQUAt3Kp+frhlsbSCdakQP/4xk7r/UwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAEhhqZTJAVbiyz4yGCazMJ/g97ulNEM3ThJj2JI4/N1naZSF S5TJw4F2U2Y+RRA94hpViPehtvAd+6EslnEmakPhdASw6X5oo3mmbEpEOg+LFJvyWDR312pR 2p2PYmToiQTR0lfpO8UgibRojjFUceigzfngxlZhhpCXlgwYm13nRYwnZ5fYGTb5zrJOX0qF hmWnRG7nJntXC+p2+e/9gW8jsCcaPbAfNi2t91z56SEWDjWECX/CIYYxDzBasqwY1o2xN2VQ SJ2YbvZy4t6zXxUGsw4JVrLy8sDoaRnOHyxvUTMV9Q0kVSo17gK0OyXSGJDyat7SdQXI4W6E nahIy3gAAAAAAAA= --------------ms000700010001090305000601-- From trevp@trevp.net Wed Feb 12 19:03:09 2014 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 EC10B1A00BB for ; Wed, 12 Feb 2014 19:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 YqeAgZdmEz-J for ; Wed, 12 Feb 2014 19:03:06 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82E1A0028 for ; Wed, 12 Feb 2014 19:03:06 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hq11so7744672vcb.14 for ; Wed, 12 Feb 2014 19:03:05 -0800 (PST) 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=TthAlpq3kzThMc73Kr+2rIvVfCC21OUFxyi6PZtfUlE=; b=WiUg/i0OM0bW53CKIuu7Ecra/cdgv1SXddJqlbRyfs32QDuL9ZaKdxTbyN79FGnSEG uRLnO7A74HgGd/nHi9Tz9sqbXefm01ypJ5OimIYFgnrmzkNmbiRXziPRkmQL9Aj1ZLI2 4sayr3qYjrejsgJeKjxGSHXsKHnCsFkb1IkMtqmOnBODXCnvxllOF5LSBfvVaj/eFkzW cazklEyerGp3ZCS8FPITMd/U0hpUEejZMd/n4kOxFV6yEWmx5Rn/1Auxh+Y1UczkY/NR 3J4mft564jzpdU+nQKgzH5XxTvDgqZPKwEl+DdhitAodbjC7hvTd6+yJihRfqMul0SQD 4b2w== X-Gm-Message-State: ALoCoQk4QRj651PA7oV5zoOfGG317bLy5BOB60e8m2uiGeXBBrN/KusC4gIKUtm3QdXdCVMZRCbm MIME-Version: 1.0 X-Received: by 10.52.166.9 with SMTP id zc9mr29626544vdb.16.1392260585038; Wed, 12 Feb 2014 19:03:05 -0800 (PST) Received: by 10.220.107.140 with HTTP; Wed, 12 Feb 2014 19:03:04 -0800 (PST) X-Originating-IP: [166.137.177.219] In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> <52F693A3.4030108@gondrom.org> Date: Wed, 12 Feb 2014 19:03:04 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Thu, 13 Feb 2014 03:03:09 -0000 On Sat, Feb 8, 2014 at 9:02 PM, Yoav Nir wrote: > Hi Trevor > > The issue on the tracker is about the interaction of dynamic pins with pre-loaded pins. The authors have written section 2.7 to address this. > > So let's bring back your points: > > * Preloaded pin stores will be periodically updated, which means > browsers will need to handle "backdated" pins, i.e. pins that are > received *after* other HPKP observations but have an "Effective Pin > Date" which is earlier. To handle these in accordance with 2.7 > requires browsers to remember "un-pinning" observations (expired pins, > max-age=0, or nonexistent HPKP headers). This is sufficiently complex > that the spec needs some treatment of it. > > * 2.7 mandates that the most recent observation from any source MUST > take priority. Browsers would not be allowed to implement other > priority rules, such as prioritizing one source over another, > prioritizing fail-open or fail-closed behavior, or anything else. I > believe this is overly restrictive. Some browsers might prefer > different policies, e.g. simpler policies that don't require tracking > "un-pinning" data. I had a more recent email (below) which describes a simple and reasonable interaction of preloaded and dynamic pins which the current spec disallows: """ There was an item to discuss "interaction between pre-loaded and dynamic pins", and some earlier discussion: http://www.ietf.org/mail-archive/web/websec/current/msg01651.html http://www.ietf.org/mail-archive/web/websec/current/msg01833.html I think the current text in draft-08 section 2.7 is unclear about what preloaded and dynamic information the browser needs to store. Most of the draft is written as if the browser is only storing active, unexpired pins. But 2.7 seems to imply the browser stores timestamped "negative observations" such as max-age=0 observations, no-header observations, and expired pins, which will override less-recently-observed pins from different data sources (preloaded overriding dynamic, or vice versa). I could imagine simpler policies. One example: * The preload and dynamic lists contain only active, unexpired pins * The browser applies pins from both lists (i.e. if both a dynamic and preloaded pin exist for example.com, they are both applied) * The browser manufacturer can push an "override" which erases bad dynamic pins for particular hostnames. This wouldn't provide automatic overriding of (preloaded/dynamic) pins based on newer observations in a different source. But it *would* allow for explicit overriding of bad dynamic pins, which seems the most important type of overriding. It also seems much simpler. I suggest we allow such different and simpler policies. If people disagree, I'd like to hear a clearer statement of: * How exactly the current policy will work (i.e. what negative information needs to be stored and how it's used). * Why it's necessary to support automatic overriding of pins from different sources based on the newest observation? """ http://www.ietf.org/mail-archive/web/websec/current/msg01938.html Trevor From trevp@trevp.net Wed Feb 12 19:22:59 2014 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 DDCF61A00AB for ; Wed, 12 Feb 2014 19:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 hhF3OfWxaC0W for ; Wed, 12 Feb 2014 19:22:56 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id B5E431A0028 for ; Wed, 12 Feb 2014 19:22:56 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id la4so7654115vcb.21 for ; Wed, 12 Feb 2014 19:22:55 -0800 (PST) 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 :content-transfer-encoding; bh=QcBi7Hwy24CBNTOJ9MoCfRETkRDtoY8SPpQVN/aKizc=; b=NPsu2gJbvMY44J+ZXqwxRtUsj39yTbmixto3M1AaApj443zBXCIkcp8jZKjquTA6IK LvkrOBN1fMn5gBmI+W2NWDIcAxWcdM9fgls98wKpBWc8aG5SI2j8XRVuA6eAGXE2vVDy rMcF1tqC17PZbelcM9LQMVhxj1dd5Auibr4xYh7U8i2HaxsqfQTNGXw5eWBPYRJfn/EG PinZPi2EUk8oe083KRhqxDgHg74rO5R02dW1b09DhXQeE7GPE+k+Z/UaW1WJxJ1hRQ+F eakHHIMEwZ0I4BPQOhh2knwEurkfPsOPLc6gZNhqQR5NtdRK5uFodhnMOFb6eiCdC8c6 UJMw== X-Gm-Message-State: ALoCoQmZ21+ScUtuzAGe6iNGAt/I19ah6OnufXTMAex72tAzFNCV3r6wenndjoGZv/TS8a3NN/DW MIME-Version: 1.0 X-Received: by 10.220.191.134 with SMTP id dm6mr34605094vcb.16.1392261775427; Wed, 12 Feb 2014 19:22:55 -0800 (PST) Received: by 10.220.107.140 with HTTP; Wed, 12 Feb 2014 19:22:55 -0800 (PST) X-Originating-IP: [166.137.177.219] In-Reply-To: <4C50494B-55D9-4621-9D78-C69B0AA5FAE3@checkpoint.com> References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <6317F824-A71B-47D8-9461-C0B785045A8F@checkpoint.com> <52F693A3.4030108@gondrom.org> <4C50494B-55D9-4621-9D78-C69B0AA5FAE3@checkpoint.com> Date: Wed, 12 Feb 2014 19:22:55 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Thu, 13 Feb 2014 03:23:00 -0000 On Sat, Feb 8, 2014 at 11:24 PM, Yoav Nir wrote: > [Replying to myself, but with no hats on] > > IMO the current text is fine. Regarding the first point, it creates a bur= den for the browser maker, but only if they update their pre-loaded pin lis= t by observation. Updating preloaded pin lists by "observation" (i.e. scanning sites for HPKP headers) is a reasonable thing for a browser maker to do. We shouldn't create an unnecessary burden for them in that case. I find section 2.7 unclear, but it seems to mandate that preloaded pin lists MUST include entries for expired pins or max-age=3D0 pins, as well as the last-observed time for each such entry and each pin, so that the browser can be sure it is using the "most recent" observation for each pin, even when that observation was negative or now expired. That seems to unnecessarily preclude simpler and more efficient implementations, which is my objection. > I think in a future where HPKP is supported in most browsers, pre-loaded = lists will contain very few entries - perhaps the big content sites and a f= ew banks, maybe Paypal. I expect that most site operators would be happier = to pin sites by themselves with an HPKP header rather than interact with al= l browser vendors. Since browser vendors could scan for HPKP headers to populate their preloaded lists I think wider use of HPKP is likely to lead to *MORE* preloaded pinning, not less. Trevor From trevp@trevp.net Wed Feb 12 21:07:20 2014 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 6D5BE1A00ED for ; Wed, 12 Feb 2014 21:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 Cljcl-DKScrO for ; Wed, 12 Feb 2014 21:07:16 -0800 (PST) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 89A241A00EF for ; Wed, 12 Feb 2014 21:07:16 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ij19so7842998vcb.34 for ; Wed, 12 Feb 2014 21:07:15 -0800 (PST) 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=R+zjGrhaET3AiFjz50CnES4pmHOtBTH8FYg9p55t9Mo=; b=iI8WV1ov8AUiCXi+MsFOGMhRPThwi6n8jC+fJT5YCMRRUIgQW1ySyLqExILaMZ9/jO rPAHq+Q551XReErkIDtxuXQoW+XCKw9uQdRQKde3+OdOSVk1wWz9D/wuF4YlbSV/3fRN g2L+o4zQF48l6ajHRouadE+6t8C0iTZzcJOBOMk/xHmEnOh0vsYXaSM9/IcdHTat1mUW Yd6nIV02HMKzwpAkexPZWB8z8XLH/Czu+/YlhqBkrJY6HWxLsALk3TGxyl1HWJbyUvry XjwByZ1f+L79J0nQ/mtpHVSJookLWmrCSFxmYbVjnKTNVhGUs8bG7cK9lqA/hM5eoB+3 nEnA== X-Gm-Message-State: ALoCoQlq0K5DIOyHNAJBllzLjopCFFt2gZjDzvKgDmTWwLjXM3IbY2rH9NLN4VUJ17cedsSZ8Jyu MIME-Version: 1.0 X-Received: by 10.58.66.137 with SMTP id f9mr35611432vet.11.1392268035208; Wed, 12 Feb 2014 21:07:15 -0800 (PST) Received: by 10.220.107.140 with HTTP; Wed, 12 Feb 2014 21:07:15 -0800 (PST) X-Originating-IP: [166.137.177.219] In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Wed, 12 Feb 2014 21:07:15 -0800 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Thu, 13 Feb 2014 05:07:20 -0000 On Fri, Feb 7, 2014 at 5:47 PM, Chris Palmer wrote: > Oops, I forgot one thing: > > On Fri, Feb 7, 2014 at 5:12 AM, Tom Ritter wrote: > >> "If a Host sets both the Public-Key-Pins header and the Public-Key- >> Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and >> MUST note only the pins and directives given in the Public-Key-Pins- >> Report-Only header." >> >> I thought we were following the CSP model, where you can enforce one >> policy, but test a second. > > Honestly, I think that's likely to be too complicated. I want to > prioritize ease of deployment (which includes a simple-to-state policy > like the above, and failing open when not unreasonably unsafe), and > I'd like for the implementation not to get too much more complicated. When we discussed PKP-RO in Nov/Dec there was uncertainty on things like: * Is the browser expected to store a PKP-RO pin, or just evaluate it against the connection that asserted it? * What happens when a server asserts both PKP and PKP-RO? The first seems like a major decision which hasn't been decided yet. On the second point, Ryan Sleevi's opinion back then was different from yours: "A PKP might specify a looser-policy, while PKP-Report-Only is used to test a more restrictive policy for deployment." http://www.ietf.org/mail-archive/web/websec/current/msg01961.html It seems you've decided differently. But that brings back an earlier question: if the PKP and PKP-RO headers can't be usefully asserted simultaneously, why have two headers at all? Shouldn't we just have a "read-only" directive in that case? In any case, the -10 and -11 drafts didn't make any clarifications to PKP-RO, so are these still open issues? There were a few other things Ryan was going to clarify about PKP-RO. Below are excerpts from that thread: http://www.ietf.org/mail-archive/web/websec/current/msg01961.html [TREVOR] Why is there a "Public-Key-Pins-Report-Only" header instead of a "report-only" directive? Most of the document is written as if there was a single "PKP header field", so a directive would make more sense. [SLEEVI] Similar to CSP. A PKP might specify a looser-policy, while PKP-Report-Only is used to test a more restrictive policy for deployment. ... Report-Only doesn't/wouldn't need to be stored, because it is a report-only mechanism. You simply evaluate the R-O on the current connection (if a directive is present) and ping back. ... To me, R-O makes most sense when treated like CSP - if present, report, otherwise, nothing. This is consistent with an implicit Max-Age: 0, because no storage is required or performed. [TREVOR] Hmm, I assumed "report-only" pins would be noted, and the draft seems written that way. **************************** [TREVOR] Section 2.5 - Does a failed validation of a "report-only" pin count as an "error" that will inhibit noting of new pins in the connection? [SLEEVI] No. Happy to clarify that. **************************** [TREVOR] Specified UA behavior with multiple header fields is contradictory: - 2.1.3: "If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins-Report-Only header." - 2.3.1: "If a UA receives more than one PKP header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field." [SLEEVI] The ambiguity is the term "PKP header field", which may be alternatively written "more than one PKP header field or more than one PKP-R-O header field". Does that satisfy your concern? Trevor From ynir@checkpoint.com Thu Feb 13 03:56:16 2014 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 1F7C31A01F2 for ; Thu, 13 Feb 2014 03:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 BocrAKw9d56t for ; Thu, 13 Feb 2014 03:56:14 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C2A791A01EF for ; Thu, 13 Feb 2014 03:56:13 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s1DBu7VO022339; Thu, 13 Feb 2014 13:56:08 +0200 X-CheckPoint: {52FCAB7A-8-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 13:56:07 +0200 From: Yoav Nir To: Trevor Perrin , IETF WebSec WG Thread-Topic: Pre-loaded pins vs dynamic pins Thread-Index: Ac8orfecmh3PnB/+T/yARi4C/x+Ndw== Date: Thu, 13 Feb 2014 11:56:07 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Pre-loaded pins vs dynamic pins 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: Thu, 13 Feb 2014 11:56:16 -0000 [ I'm forking the thread so as to avoid confusing it with the other issue ] Section 2.7 ( http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#s= ection-2.7 ) describes the interaction between pre-loaded pin lists and the= dynamic pins that the UA observes. The draft says that any later observation (new pin, unpin, missing pin) alw= ays trumps an earlier observation. Seems right, except this creates an inte= resting issue with updates to the pre-loaded pin list, such as when there a= re browser updates, or just a dynamic update from the list: - what happens if a pin in the fresh list differs from a dynamic pin? - what happens if a pin that is in the list is one that had been unpinned = before? One way is to require the static list to have "observation dates" for each = entry, and also require the UA to keep track of all noted pins for the life= time of that pin. By keeping track I mean recording all replacement and unp= inning events, including dates, so as to be able to construct a timeline wi= th the static list, and be able to tell which event happened last. For exam= ple, if the UA notes a pin on 1-Feb, then notes an unpinning on 9-Feb, then= on 15-Feb it downloads a new list with the old pin observed at 7-Feb, the = pin should remain deleted. Another way is to treat all updates from the static pins as if they had jus= t been observed at the moment of download. That is obviously much easier to= implement. A third way (Trevor's) is to treat the static and dynamic pins as two separ= ate pin databases, both of which are enforced and no interaction between th= em. But the UA vendor can also push updates for deleting dynamic pins, to s= ave web site operators who have shot themselves in the foot. Yet a fourth way is to observer that none of this affects interoperability = in any way and leave it up to the UA vendor to choose their way. The web si= te operator should only include valid pins in their HPKP headers, and they = should also enter only valid pins in pre-loaded lists. They should also dea= l with the fact that don't control usage patterns, so anytime they pin some= thing for X seconds, their website MUST conform to that pin for at least th= ose X seconds or bad things will happen. =20 Trevor: if I didn't capture your opinion, please correct me. People other than Trevor: I don't really believe that only Trevor cares abo= ut this issue. Please speak up about these alternatives above Thanks Yoav From nobody Thu Feb 13 11:42:49 2014 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 6DA481A0421 for ; Thu, 13 Feb 2014 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 7RFEp72AEu27 for ; Thu, 13 Feb 2014 11:42:43 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id A03451A03FA for ; Thu, 13 Feb 2014 11:42:43 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id p5so8395948vbn.2 for ; Thu, 13 Feb 2014 11:42:42 -0800 (PST) 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 :content-transfer-encoding; bh=FnFgBY39rZU0SsowzNZi/miVHUiZkmvH1T3hnl0Onlo=; b=EyiqSVRcD2AZAHdgpRpvlNei75TrVIZD2nnEBR3hM+KT8S1qAVMcckB5IEjhWyG/L5 WvQe3mtWfJNBTC0y7ZKUtzRy9b0gLR7KY+Z9PruDo5TWYGAeKpiikYpBI1SgQGgkmyGz wSsSBeuo9XxFvJ874CjO/rDVdUoZf1QLzf7DurvuuaFBDdKpOfvS7uhvoA+mFA1j0zBD jy3FDKL+oTREaGaIZWsYF5w6elqh+hCE1fnb9wY0sdv08AqJT1ltTUEtBLRVQFYVd0Kw i2x+13yD2z6fDe1xr3qAylN5wzipGsir8lje9NKtSXR1DdBg39hEEiMOFuNJ/fYn5dJ/ GYVw== X-Gm-Message-State: ALoCoQkNPwjJwcVebuMyRUj7RTwkRvi+Eo1Y9R3RIG/XFXLN3IIj2wAJigchom7DZ97v2M/CK2mC MIME-Version: 1.0 X-Received: by 10.221.66.73 with SMTP id xp9mr1976135vcb.27.1392320561949; Thu, 13 Feb 2014 11:42:41 -0800 (PST) Received: by 10.220.107.140 with HTTP; Thu, 13 Feb 2014 11:42:41 -0800 (PST) X-Originating-IP: [166.137.177.219] In-Reply-To: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> Date: Thu, 13 Feb 2014 11:42:41 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/lb_SUTpurQKhajM1X4G_0wSoT4Q Cc: IETF WebSec WG Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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: Thu, 13 Feb 2014 19:42:46 -0000 On Thu, Feb 13, 2014 at 3:56 AM, Yoav Nir wrote: > [ I'm forking the thread so as to avoid confusing it with the other issue= ] > > Section 2.7 ( http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11= #section-2.7 ) describes the interaction between pre-loaded pin lists and t= he dynamic pins that the UA observes. > > The draft says that any later observation (new pin, unpin, missing pin) a= lways trumps an earlier observation. Seems right, except this creates an in= teresting issue with updates to the pre-loaded pin list, such as when there= are browser updates, or just a dynamic update from the list: > - what happens if a pin in the fresh list differs from a dynamic pin? > - what happens if a pin that is in the list is one that had been unpinne= d before? > > One way is to require the static list to have "observation dates" for eac= h entry, and also require the UA to keep track of all noted pins for the li= fetime of that pin. By keeping track I mean recording all replacement and u= npinning events, including dates, so as to be able to construct a timeline = with the static list, and be able to tell which event happened last. For ex= ample, if the UA notes a pin on 1-Feb, then notes an unpinning on 9-Feb, th= en on 15-Feb it downloads a new list with the old pin observed at 7-Feb, th= e pin should remain deleted. Almost, but note that an unpinning event might be an observation of a max-age=3D0 header, *or* a pin expiring (in which case the browser would need to keep remembering the expired pin for some period along with the time of last observing the header, *not* the expiration date). So in your example - if the "unpinning" on 9-Feb is an HPKP observation of max-age=3D0 then it would trump the preloaded pin's 7-Feb observation date, but if it was an expiration of an 8-day pin it would not, it would only trump preloaded observations prior to 1-Feb... > Another way is to treat all updates from the static pins as if they had j= ust been observed at the moment of download. That is obviously much easier = to implement. Seems fine, as long as the duration of those pins does not exceed what the site has asserted. > A third way (Trevor's) is to treat the static and dynamic pins as two sep= arate pin databases, both of which are enforced and no interaction between = them. But the UA vendor can also push updates for deleting dynamic pins, to= save web site operators who have shot themselves in the foot. Yeah, I think this ability to un-pin sites who screw up will (sadly) probably be necessary. > Yet a fourth way is to observer that none of this affects interoperabilit= y in any way and leave it up to the UA vendor to choose their way. The web = site operator should only include valid pins in their HPKP headers, and the= y should also enter only valid pins in pre-loaded lists. They should also d= eal with the fact that don't control usage patterns, so anytime they pin so= mething for X seconds, their website MUST conform to that pin for at least = those X seconds or bad things will happen. Your "fourth way" is well-put, and I agree - all of these seem valid implementations which should be allowed. Trevor From nobody Wed Feb 19 12:10:03 2014 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 581241A0250 for ; Wed, 19 Feb 2014 12:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 gXmDD-rh14SD for ; Wed, 19 Feb 2014 12:09:59 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD71A0167 for ; Wed, 19 Feb 2014 12:09:58 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s1JK9nC1031168; Wed, 19 Feb 2014 22:09:49 +0200 Received: from IL-EX10.ad.checkpoint.com ([169.254.2.228]) by DAG-EX10.ad.checkpoint.com ([169.254.3.228]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 22:09:49 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Pre-loaded pins vs dynamic pins Thread-Index: Ac8orfecmh3PnB/+T/yARi4C/x+NdwANQaeAAS6x6oA= Date: Wed, 19 Feb 2014 20:09:49 +0000 Message-ID: <7D003007-1B62-4365-8B0E-28647FBB21C8@checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.182] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Qw5J2kjuwrlAvmwEXsqYooI1iY4 Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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, 19 Feb 2014 20:10:01 -0000 Sigh, the silence is deafening. Does anyone (and that includes the authors) object to relaxing the requirem= ents in section 2.7, so that the choice of when the static pins are believe= d to have been observed is left to the implementer? If not, we'll resolve = it that way. Note, however, that the authors cannot update the draft until IETF week, bu= t we can gather the required changes. Please respond. Thanks, Yoav On Feb 13, 2014, at 9:42 PM, Trevor Perrin wrote: > On Thu, Feb 13, 2014 at 3:56 AM, Yoav Nir wrote: >> [ I'm forking the thread so as to avoid confusing it with the other issu= e ] >>=20 >> Section 2.7 ( http://tools.ietf.org/html/draft-ietf-websec-key-pinning-1= 1#section-2.7 ) describes the interaction between pre-loaded pin lists and = the dynamic pins that the UA observes. >>=20 >> The draft says that any later observation (new pin, unpin, missing pin) = always trumps an earlier observation. Seems right, except this creates an i= nteresting issue with updates to the pre-loaded pin list, such as when ther= e are browser updates, or just a dynamic update from the list: >> - what happens if a pin in the fresh list differs from a dynamic pin? >> - what happens if a pin that is in the list is one that had been unpinne= d before? >>=20 >> One way is to require the static list to have "observation dates" for ea= ch entry, and also require the UA to keep track of all noted pins for the l= ifetime of that pin. By keeping track I mean recording all replacement and = unpinning events, including dates, so as to be able to construct a timeline= with the static list, and be able to tell which event happened last. For e= xample, if the UA notes a pin on 1-Feb, then notes an unpinning on 9-Feb, t= hen on 15-Feb it downloads a new list with the old pin observed at 7-Feb, t= he pin should remain deleted. >=20 > Almost, but note that an unpinning event might be an observation of a > max-age=3D0 header, *or* a pin expiring (in which case the browser would > need to keep remembering the expired pin for some period along with > the time of last observing the header, *not* the expiration date). >=20 > So in your example - if the "unpinning" on 9-Feb is an HPKP > observation of max-age=3D0 then it would trump the preloaded pin's 7-Feb > observation date, but if it was an expiration of an 8-day pin it would > not, it would only trump preloaded observations prior to 1-Feb... >=20 >=20 >> Another way is to treat all updates from the static pins as if they had = just been observed at the moment of download. That is obviously much easier= to implement. >=20 > Seems fine, as long as the duration of those pins does not exceed what > the site has asserted. >=20 >=20 >> A third way (Trevor's) is to treat the static and dynamic pins as two se= parate pin databases, both of which are enforced and no interaction between= them. But the UA vendor can also push updates for deleting dynamic pins, t= o save web site operators who have shot themselves in the foot. >=20 > Yeah, I think this ability to un-pin sites who screw up will (sadly) > probably be necessary. >=20 >=20 >> Yet a fourth way is to observer that none of this affects interoperabili= ty in any way and leave it up to the UA vendor to choose their way. The web= site operator should only include valid pins in their HPKP headers, and th= ey should also enter only valid pins in pre-loaded lists. They should also = deal with the fact that don't control usage patterns, so anytime they pin s= omething for X seconds, their website MUST conform to that pin for at least= those X seconds or bad things will happen. >=20 >=20 > Your "fourth way" is well-put, and I agree - all of these seem valid > implementations which should be allowed. >=20 >=20 > Trevor From nobody Wed Feb 19 13:13:15 2014 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 AA08E1A05E7 for ; Wed, 19 Feb 2014 13:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 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, RP_MATCHES_RCVD=-0.548, 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 tRWs_Rt9-bnm for ; Wed, 19 Feb 2014 13:13:10 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 659771A0226 for ; Wed, 19 Feb 2014 13:13:10 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id h3so1911287igd.5 for ; Wed, 19 Feb 2014 13:13:07 -0800 (PST) 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:content-transfer-encoding; bh=vNTmcrwXIsNeyN0DEmPhBTQHFHGIkJ1EEWOi9gqw/KE=; b=OFRGbqZVOXXlJNpzUaS8hH5fXJrqA7BdYYtFfSGS3ZVXmayF9kQXjyFm1kvH7PLQse IHS3D2dddyeGAVNyE8RrGdsRoRWU2trIMs/sfy3TRwXzKSYapvVobu7fbLtnIwLhw2dH UpkfPizZ2/eE/Vtl/jUxLBfuD10pcE8bwPNEcdlbgeC3BUGvooEJUPW9Tnh43cgtWkgL MF6klY7U4QArxsGN4aLKhDOh2210USyWX05AeRs7JjQoek8tjOvsuLxMg6BZDzbU9us4 zmNFDvoRXEn4M5FL7miIYMwQS0f25niiKahzWZIOndNwQcf+x31/e3rYGHbdf4LHpZoH MzLA== 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 :content-transfer-encoding; bh=vNTmcrwXIsNeyN0DEmPhBTQHFHGIkJ1EEWOi9gqw/KE=; b=M0OMaiIPsqJTxI37FeEiGr57asOURtlHmGih0ryqMDJRGvuRxAM9d010EjANfRbMrc fKSn7JA5y82Zs8Ro85dfhbO8xguZRIoEyVBVnMCETu3OfGFy108wxA2iwhdA+xfkwcDd E+n2mHSuFzfMTLt9CgBCo14SgTxLdH2rss6Z95iGeFLwcPEPYCC9ilhIun8lPxvLf2sf P827OdxUgAwjPkv9vcGTDPMnp8DHMe2CvEoNbhCMuMtQqSfXtDOoJFttEvbmgw9w7/fB S31onM9r+WYZoR+uVto2TG8EgLtfqp9pNP8bGg3Zjff+nZnXk20z6Dm8ojDiq7aBF/Ib LsMw== X-Gm-Message-State: ALoCoQn7UsNOP9kwk4BebYfDa1HSPe85DQX+1Psp49PYCbJwUs62HFb6u0ySrGJFusKBs3znPP4dHDhiKWaUp0c1nC3PBuYekvpQEFm4sIlmOnSQAZXEo7K7HlJ8K0NFV+R8657ihijdlopCU17O0HbFhdAzKRcRiZzsSGcj8epdKv0wmI6ZycNP/TXWdSgzoId1W+CUBvhG MIME-Version: 1.0 X-Received: by 10.50.47.110 with SMTP id c14mr3539104ign.4.1392844387027; Wed, 19 Feb 2014 13:13:07 -0800 (PST) Received: by 10.64.165.2 with HTTP; Wed, 19 Feb 2014 13:13:06 -0800 (PST) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> Date: Wed, 19 Feb 2014 13:13:06 -0800 Message-ID: From: Chris Palmer To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/y2bORXPM54vjMkuTIDg02E-KkwA Cc: IETF WebSec WG Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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, 19 Feb 2014 21:13:12 -0000 On Thu, Feb 13, 2014 at 11:42 AM, Trevor Perrin wrote: >> Yet a fourth way is to observer that none of this affects interoperabili= ty in any way and leave it up to the UA vendor to choose their way. The web= site operator should only include valid pins in their HPKP headers, and th= ey should also enter only valid pins in pre-loaded lists. They should also = deal with the fact that don't control usage patterns, so anytime they pin s= omething for X seconds, their website MUST conform to that pin for at least= those X seconds or bad things will happen. > > Your "fourth way" is well-put, and I agree - all of these seem valid > implementations which should be allowed. I have been thinking that this 4th way is the way to go. Note for example that RFC 6797 (HSTS =E2=80=94 which I would still like for HPKP to emulate) does not even cover the topic. From nobody Wed Feb 19 13:14:08 2014 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 B68371A05E7 for ; Wed, 19 Feb 2014 13:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 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, RP_MATCHES_RCVD=-0.548, 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 Y60e6oJGmUYm for ; Wed, 19 Feb 2014 13:14:05 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA681A0226 for ; Wed, 19 Feb 2014 13:14:05 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id c10so2075213igq.0 for ; Wed, 19 Feb 2014 13:14:01 -0800 (PST) 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=IyLUOEclTuek7Lp1bpy+61BHuANRvXzUgJImELwWgEE=; b=G0oZLTkIHqGk5vcywm0ehFgDMndbyAzA63ZWa+8OBngdPSuynDusZZ6KQEPq1cQZ1z HxdwRJetkQ9GHSHuVb+WF2VSs9krGmPu90NWRIxGbwfopEru0IyIZ145YRf2m0acDab8 R78njQOfwDkCC509kHpHYAtGwUExAuLa/g/CRk8kfOQ7qK9OYoSkJHBgEM9aAW6MZo9l 6ECgR5HLl90xMHq+Bs2W5N52fEhUjoL1QBX20ITIejbe7RdLVf21RkNu8gXs0IVJiIci dpUmbH5GBcolf0gpEXO7jaEAr7tzoDoFQJY/ScJVWKi2JpVA4DQQ3LqJlGMqQ8YTYG9A CKAw== 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=IyLUOEclTuek7Lp1bpy+61BHuANRvXzUgJImELwWgEE=; b=MCvGQjFi1Djn3vcmzf3ZmNKiP5tx0ylswSTqdXAnzYD/rgLDCjjNao2Jorr1AO7v8K ZO5jhHU+Fx2rMYV23OFH5RS2p/qkr0JZm33RHliLk1/aYcU0td3P0opGkS3z5JbrUYhC Pp0+HGkdUiKUkw59EFwU/Su+zbcZoQZ8iLJ1FV7Y5TUbgfNkUoBTMwXjQXzg8x2Bged5 miQejyKeHLx28lXRA0nNcjr4yFa5NPKrUCZ63N9uPfide3JSdk7dpkQzirJ0iNG8V7pL dGk7aCBaG9aeV99JZJhCiORnpMATuADlp9YhpFnFMqULZtJH4zMIAf8+IG49cSYcnOnI k0aw== X-Gm-Message-State: ALoCoQmMF3j2SUsWRv7KDX7/j0jPEAx8Otrotih6WHgt2lWmk6u9SK5iIgKDcgrbA4M2NqkyrV+FPunBfQHVzX44vXJ1fuH5jL6AbbJyc12MGj5vY3QGhg28yy6OMXDj9aUhHzTyF39Wl3MLGd5Rwkv6u1V/XJwia1Evw7JivdZac6QhEVPC/Qppk/di4L/dJ3165BVSW+TF MIME-Version: 1.0 X-Received: by 10.43.182.74 with SMTP id pl10mr2459882icc.70.1392844441795; Wed, 19 Feb 2014 13:14:01 -0800 (PST) Received: by 10.64.165.2 with HTTP; Wed, 19 Feb 2014 13:14:01 -0800 (PST) In-Reply-To: <7D003007-1B62-4365-8B0E-28647FBB21C8@checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> <7D003007-1B62-4365-8B0E-28647FBB21C8@checkpoint.com> Date: Wed, 19 Feb 2014 13:14:01 -0800 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/2eXzzznsf9EeG_692paFpXWpqoA Cc: IETF WebSec WG Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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, 19 Feb 2014 21:14:07 -0000 On Wed, Feb 19, 2014 at 12:09 PM, Yoav Nir wrote: > Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way. I don't object; I like that well enough. From nobody Wed Feb 19 14:30:06 2014 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 928871A0239 for ; Wed, 19 Feb 2014 14:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 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, RP_MATCHES_RCVD=-0.548, 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 stZVWORtBK6U for ; Wed, 19 Feb 2014 14:30:02 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 229C11A02BE for ; Wed, 19 Feb 2014 14:30:01 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id rd18so731215iec.17 for ; Wed, 19 Feb 2014 14:29:58 -0800 (PST) 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=M7cJsVrQy9nMETjY4M7dY+FamSNiDhCvlchsQ3hIIVo=; b=ozQ8tBeyHgMkhkY7I9V6Es+pY6kvk4jCll7Sbhn6pKCv6LHcaU2HgsEY5HaoFFwBh6 TDtTURknKEyqJp6hlaH4YU/vvVr6WsW/RITd5ES9xR5prhQoxRmHgR18KkTrCbH8QyZI 7YfKe462EBLs++WuLUc5i9nWs1MH6jz86kdsBYllZo6QFR4ZOJP6PzZH5+TDhYcRfBfa 2g7Cnj6EpG8dBDr8AnovXjRKBlayLvm1EKiokCdYfJZ6V2kIlkQ4vAhoi8XajwEEFDRb 2GJbHgKg1QwIxCrAbMLSZ15tFNm5e5Osg/MRUqQcrGnQkob0Rafp8az7QMtV7Uwchi2S jsuw== 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=M7cJsVrQy9nMETjY4M7dY+FamSNiDhCvlchsQ3hIIVo=; b=hhGPC1z2GcdBpWOPM3gMCsRyOd+OM9BoALKgZBff0cqsphpw9auAqpd4hj5mcuwXSi M3ujib9GN4E6h2T6QI2lzH0eTeI+uag6Xyykj5+vKKhal37eWPHfJAddKyyNS4p6DWTa 9h74s/jBitLgDlIdfRl6dpceCyRwS7DXkojrzRzgtBz4dgCkl4mLii7/8OQDvE+nYapH jJroMsLL5QQLKmiFJGgVzfnnn+xAhbWwMiZXZkJrl10xtSCbO8SYGfcpeH3uXjojDNJx rtt96dsN8c/ZdfmvoXGXe4wU+72Uq8Sw2Y6i7wIsqm3Q/7zlVSOUOkp1oBu48scPYfhJ egzA== X-Gm-Message-State: ALoCoQkToP2ZrpSe8GGpsTqfJLy00VJHoaJJ4ulo7pvJzEV9yN4ae8VvOBbSw9jZeN85eCWgs8EebAX/zfi8W6dsCkPo/SoJoz+LO/ycJD9Itc9lzeuT49zA2wPkaUF7vLM4mYhfF1tcXIMUVotgBpW0XvbUP0Gg8PKJ0tdagGPLd0KYDF4HrlRo0J8AtJd9RnoN8Ah/e0wB MIME-Version: 1.0 X-Received: by 10.43.51.65 with SMTP id vh1mr28975886icb.24.1392848998514; Wed, 19 Feb 2014 14:29:58 -0800 (PST) Received: by 10.64.165.2 with HTTP; Wed, 19 Feb 2014 14:29:58 -0800 (PST) In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Wed, 19 Feb 2014 14:29:58 -0800 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/DjZLo0tGSI9xm751Q6hckczGMPo Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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, 19 Feb 2014 22:30:04 -0000 On Wed, Feb 12, 2014 at 4:26 AM, Yoav Nir wrote: > Section 1, first sentence begins with "We propose a new...". Our target is > called "proposed standard", but I think it would be better to say "We define > a new HTTP header..." That is currently what it says. (https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-websec-key-pinning.xml) > Fourth paragraph in section 2.1.3 is kind of clunky: > > OLD > "When used in the Public-Key-Pins header, the presence of a report-uri > directive indicates to the UA that the UA MUST enforce Pin Validation, and > the UA SHOULD also, in the event of Pin Validation failure, POST a report to > the report-uri." > > The presence of the report-uri directive has nothing to do with the UA > having to enforce pin validation. That is required by any PKP header. How > about rewriting this as: > NEW > "When used in the Public-Key-Pins header, the presence of a report-uri > directive indicates to the UA that it SHOULD also, in the event of Pin > Validation failure, POST a report to the report-uri." Agreed. Making that change now. > Section 2.5. > Section 2.4 says that future versions may add new algorithms. So we should > be prepared for new algorithms. Section 2.5 says "For forward compatibility, > the UA MUST ignore any unrecognized Public-Key-Pins header directives, while > still processing those directives it does recognize." So suppose the UA got > the following header: > > Public-Key-Pins: max-age=2592000; > pin-sha4-256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; > pin-sha4-256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" > > Not having support for SHA4, it can't validate or use these pins. That is > fine when the server keys are not yet pinned. Now suppose that the server is > pinned (because previously it expressed HPKP with a SHA2-256. Does the UA > (a) ignore it, keeping the old pin, or (b) treat this as unpinning? Either > way, where does it say so? I don't think the text currently handles this case. And, I don't know which of (a) or (b) is preferable. It's a bit of a pathological case; why would a site operator send such a header, knowing as they do that the current version of HPKP specifies only SHA-256 (i.e. SHA2-256)? In future versions, in which we hypothetically add support for SHA4 (or whatever future hash function), presumably we'd include some language about this. But for now, any site operator doing this would be making a mistake. From nobody Wed Feb 19 14:49:10 2014 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 5400C1A051C for ; Wed, 19 Feb 2014 14:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, SPF_PASS=-0.001] autolearn=no 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 G9k_Gfzlrl7o for ; Wed, 19 Feb 2014 14:49:05 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 19AC01A050B for ; Wed, 19 Feb 2014 14:49:05 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id jt11so1019345pbb.39 for ; Wed, 19 Feb 2014 14:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YWG/49TUHpjmd/eANVWw3aqIywDWQCatVryChbn8Wzs=; b=yg4DuzJn5g3vzVgxG6DHiw3zpr721PLS7eCo7HhExPv+UQYL5zNOEcAH0RMPqVQyDb ZTYbaXto3d2a0NfZx4rs2Fy0+cLe1/O59MDklO0HjSkSjSNkcPK+6ylA3+UniMn26w+V L1AwH2yKoTJHlEggYM7dKdQU5SndNo7c8SK4o= 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:from:date :message-id:subject:to:cc:content-type; bh=YWG/49TUHpjmd/eANVWw3aqIywDWQCatVryChbn8Wzs=; b=fkcMjniv5sZqgVJnLI9c2oLlwVJaQttG9qlI533Hs9wuydmf56xNemg3g2XIR6lyt8 RxGQK38pxbTxhA/6/L65JO9eV5NPaAKVYVyBfxjd4cGS4vcV28Cf2IIwTS/BG8d5b/We uWAQ18tu0InMbWG2xWpkKvEx6nqdPTSy2FUjDexM2sJb8VyI86YLQTbcM3DcjlhPWItt 2iPFt6EuTVHdgG7UZlq48nBhUSj7TECrXGcZN2K/XiScBAcSgMM5wi6Gtpi/U7MnN/iX YVlavMzSW4w61zQsd2jVg5tZzo46jW9vzVspS9C2RvMXI6pLUvhk7BbsWXiZyBK928yP 5RDg== X-Gm-Message-State: ALoCoQl8lI2gLQl4NV0927QL/RT6qVuBgAVQiJxN/IKazfkr3buMeLqo+1O8F9mccI+zndqFSOnU X-Received: by 10.66.66.135 with SMTP id f7mr20584804pat.22.1392850141845; Wed, 19 Feb 2014 14:49:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Wed, 19 Feb 2014 14:48:41 -0800 (PST) In-Reply-To: References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> <7D003007-1B62-4365-8B0E-28647FBB21C8@checkpoint.com> From: Tom Ritter Date: Wed, 19 Feb 2014 17:48:41 -0500 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/2Hb3H98RLHCvP1e40NFkfVwLG4w Cc: IETF WebSec WG Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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, 19 Feb 2014 22:49:06 -0000 On 19 February 2014 16:14, Chris Palmer wrote: > On Wed, Feb 19, 2014 at 12:09 PM, Yoav Nir wrote: >> Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way. > > I don't object; I like that well enough. Seconded/Thirded/Fourthed -tom From nobody Wed Feb 19 15:05:31 2014 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 16D681A0529 for ; Wed, 19 Feb 2014 15:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 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, RP_MATCHES_RCVD=-0.548, 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 FBdwxB_up4HC for ; Wed, 19 Feb 2014 15:05:27 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 253831A04D2 for ; Wed, 19 Feb 2014 15:05:27 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id rd18so756931iec.17 for ; Wed, 19 Feb 2014 15:05:23 -0800 (PST) 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=3zdkZue7aJ2VSdh+jolyhjRzru02rDkZ4D7ndZ9XAiM=; b=dSf2o04Ag+lFiAITG6PKRQemrftT/+hUc+BvxbFUY+5UolcP2RDDaKjG30x47DKaxa F7XNmJGp4nqk5o3JZUbAEOh1iBgeeJPo0aN98r7YveVk/RlFX7FJY5cp+gNhy6x4YqRP DDSFj+632qmAMUzSSHCzOXeBmMLlA92X0ACqclzqNNTWdlp8GxyJo4Sx3Bw8IveXtjTd TN/ObTEGgbhLMULEsTCgUcInDZQQPJXhFi3qCaDU0E6jZAa3qjiFe95n+HqYUt+szBaO xIzcncXOG/29oLMjiuMrKE0vIYeGDn4sR7iXxUN4/F9fDXqfWp8dkCCPOALpaWZSlhrS UNTA== 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=3zdkZue7aJ2VSdh+jolyhjRzru02rDkZ4D7ndZ9XAiM=; b=j/VA7XhX5vVz824beoQwbyukTvLb9bCRuc9G1sLZ7g0ynVZjrM9AQWTrprxuR0OzHt K+tj9PRVe1HD290I6XYcWgS3s0KNKBjDC11aaeroKEhna19639jXYYhaPEonBRGaNOIA aYdr6lb5yMDul3AQV093tmFB2POaU30837jtGKhDfSBOmrwAr/AgDnndvHMv3SEQK/5V TdAbLTBUyrZyig9NHx4c0TZMLFMu5ewK9GKDvX5ew3gOjKpgcippdzUXmy02ImSG4nWj C7yM7iC51EZCG0WBDk6874l1QMoQ2JwJlyPRXtH1f9lQ9gjHhU+B90eltQmikit8nAbQ 3MdA== X-Gm-Message-State: ALoCoQnLakpGbzT8dvnywcsrL477ieCoAWoP6DQFD1YwTuSf/VuTrz0Yo0Fyxh38q3JTikJKTxW2/lLEIPqa9MJgauJopjGcAlWXzm1ULctl3eZFDv0CSwmuSqrnLQTaPc0izBonnR0mZ7UdB/cCTUK5hLOOjDo5/usKLbxWP/wjRCtX7lvnyoS3h8AC12ku3RlmqbRdp+iA MIME-Version: 1.0 X-Received: by 10.50.137.100 with SMTP id qh4mr3949427igb.4.1392851123753; Wed, 19 Feb 2014 15:05:23 -0800 (PST) Received: by 10.64.165.2 with HTTP; Wed, 19 Feb 2014 15:05:23 -0800 (PST) In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Wed, 19 Feb 2014 15:05:23 -0800 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/OuDhk5ddCzIETtbG5oa47c53SCY Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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, 19 Feb 2014 23:05:29 -0000 On Sat, Feb 8, 2014 at 8:47 AM, Tom Ritter wrote: >> Honestly, I think that's likely to be too complicated. I want to >> prioritize ease of deployment (which includes a simple-to-state policy >> like the above, and failing open when not unreasonably unsafe), and >> I'd like for the implementation not to get too much more complicated. > > I suppose. I think the extra implementation complication is in > conditionally applying code rather than having to write additional code, > which strike me as different, but you would know better than me. You're right, but even that feels complicated right now. :) > And that deployment would actually be made more confusing, not less, by > having two analogous headers, named in the same pattern, that behave > differently - I think that's likely to cause as much confusion as anything > else. Yeah, I see that. I think I'll have to change the text to allow the CSP-style enforce 1 policy, report on another behavior. So, how about this: If a Host sets both the Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin Validation as specified by the Public-Key-Pins header, and SHOULD note and the Pins and directives given in the Public-Key-Pins-Report-Only header. If the UA does note the Pins and directives in the Public-Key-Pins-Report-Only header it SHOULD evaluate the specified policy and SHOULD report any would-be Pin Validation failures that would occur if the report-only policy were enforced. From nobody Wed Feb 19 15:14:09 2014 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 32B331A02E5 for ; Wed, 19 Feb 2014 15:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, SPF_PASS=-0.001] autolearn=no 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 LLljW1bhhIAO for ; Wed, 19 Feb 2014 15:14:05 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 828221A0289 for ; Wed, 19 Feb 2014 15:14:05 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id lj1so1053491pab.40 for ; Wed, 19 Feb 2014 15:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lnoP4tvYED9k1GiGRBQV0qDeo2+FZKAZbqiTfPtJklc=; b=Eg68i0YLkObqySbsy8k/PgUEHK9zt42DXBI0FrvlIv8IjOI0w/cB/Qi6N+l5D5eLiL PjaURThPVvuC/fwvmNPOdLF9n0Cn4NBH3+uU/UwC8ZNPZfNcQEnuKBeVk81RiuxTUMHY hcjhFOSVFVvHUt/Sak5AexjPqTSVkLahBh9jI= 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=lnoP4tvYED9k1GiGRBQV0qDeo2+FZKAZbqiTfPtJklc=; b=eGbPQ8ErYiThRtkOC97/RD5515jHH3TKqLhfoRKL6XjFeNNgYXAqwZJYnkcism51NC cnVmgtHNzmQxc4lgZeRtdKCMOXDXINXFryQTalUT1yCP6VpmJCUAFT6B3c4mrwUN9Lfg 7U/oDpaoTOjTQiXyMASu/OQADEyaDjowNOXT24DQwVkE44OCa+6bQiXYd7no9deEQjoQ xhLhi9HPeGO74UjkuCnwUdOiJKU9REQmGxhuPBYee/oSG0GyaB+n0FGO9UESQa14++oU 5bSs8w3QaR+ld1kvJotPo/+q4/yy2hAdKh3Ujm8rDbvMOUdcLcoz5HmZOFQr1LUfWzZY jBRQ== X-Gm-Message-State: ALoCoQmltkft3ziM8QtfnDz0bDRDpHeYSPjPhB34SPWCm5ZUqgF5N7yI0u89V3Cm/mJm+MIzxlcR MIME-Version: 1.0 X-Received: by 10.68.93.132 with SMTP id cu4mr5190939pbb.129.1392851642211; Wed, 19 Feb 2014 15:14:02 -0800 (PST) Received: by 10.68.198.68 with HTTP; Wed, 19 Feb 2014 15:14:02 -0800 (PST) Received: by 10.68.198.68 with HTTP; Wed, 19 Feb 2014 15:14:02 -0800 (PST) In-Reply-To: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> Date: Wed, 19 Feb 2014 18:14:02 -0500 Message-ID: From: Tom Ritter To: Chris Palmer Content-Type: multipart/alternative; boundary=047d7b6d8f165bff6004f2ca8b56 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/1BmlqUqh8bmhf0NKLiffqVUCaqc Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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, 19 Feb 2014 23:14:07 -0000 --047d7b6d8f165bff6004f2ca8b56 Content-Type: text/plain; charset=ISO-8859-1 On Feb 19, 2014 6:05 PM, "Chris Palmer" wrote: > > And that deployment would actually be made more confusing, not less, by > > having two analogous headers, named in the same pattern, that behave > > differently - I think that's likely to cause as much confusion as anything > > else. > > Yeah, I see that. I think I'll have to change the text to allow the > CSP-style enforce 1 policy, report on another behavior. > > So, how about this: > > If a Host sets both the Public-Key-Pins header and the > Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin > Validation as specified by the Public-Key-Pins header, and SHOULD note and "And the pins" is a typo. I'm not clear what note means in this context. You probably mean "not ignore", but I don't know the least ambiguous verb to use? In any event, I like the sentiment. > the Pins and directives given in the Public-Key-Pins-Report-Only header. If > the UA does note the Pins and directives in the Public-Key-Pins-Report-Only > header it SHOULD evaluate the specified policy and SHOULD report any > would-be Pin Validation failures that would occur if the report-only policy > were enforced. (Sent on a phone) --047d7b6d8f165bff6004f2ca8b56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 19, 2014 6:05 PM, "Chris Palmer" <palmer@google.com> wrote:
> > And that deployment would actually be made more confusing, not le= ss, by
> > having two analogous headers, named in the same pattern, that beh= ave
> > differently - I think that's likely to cause as much confusio= n as anything
> > else.
>
> Yeah, I see that. I think I'll have to change the text to allow th= e
> CSP-style enforce 1 policy, report on another behavior.
>
> So, how about this:
>
> <t>If a Host sets both the Public-Key-Pins header and the
> Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin > Validation as specified by the Public-Key-Pins header, and SHOULD note= and

"And the pins" is a typo. I'm not clear what n= ote means in this context.=A0 You probably mean "not ignore", but= I don't know the least ambiguous verb to use? In any event, I like the= sentiment.

> the Pins and directives given in the Public-Key-Pins-Re= port-Only header. If
> the UA does note the Pins and directives in the Public-Key-Pins-Report= -Only
> header it SHOULD evaluate the specified policy and SHOULD report any > would-be Pin Validation failures that would occur if the report-only p= olicy
> were enforced.</t>

(Sent on a phone)

--047d7b6d8f165bff6004f2ca8b56-- From nobody Wed Feb 19 15:27:09 2014 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 5982C1A02BE for ; Wed, 19 Feb 2014 15:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 Tojj4Sp7tfhz for ; Wed, 19 Feb 2014 15:27:05 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1587C1A02A1 for ; Wed, 19 Feb 2014 15:27:04 -0800 (PST) Received: from [10.250.23.45] (guest-224.mv.mozilla.com [63.245.220.224]) (Authenticated sender: dveditz@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4A21CF22F4 for ; Wed, 19 Feb 2014 15:27:01 -0800 (PST) Message-ID: <53053DC9.40208@mozilla.com> Date: Wed, 19 Feb 2014 15:27:05 -0800 From: Daniel Veditz User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF WebSec WG References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/kigZ-P1bxp2H5ZMvjgahB5W54tE Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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, 19 Feb 2014 23:27:07 -0000 On 2/19/2014 1:13 PM, Chris Palmer wrote: > On Thu, Feb 13, 2014 at 11:42 AM, Trevor Perrin > wrote: > >> Your "fourth way" is well-put, and I agree - all of these seem >> valid implementations which should be allowed. > > I have been thinking that this 4th way is the way to go. Note for > example that RFC 6797 (HSTS — which I would still like for HPKP to > emulate) does not even cover the topic. The pre-load list seems outside the mechanism covered by the spec. At best the spec could mention it in a non-normative section as something UAs can do to cover the first-visit gap, but there are several valid ways such a list could be implemented. -Dan Veditz From nobody Thu Feb 20 03:18:13 2014 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 6F3D71A00D7 for ; Thu, 20 Feb 2014 03:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 Fcq__s94Pasm for ; Thu, 20 Feb 2014 03:18:10 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD481A00AB for ; Thu, 20 Feb 2014 03:18:09 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s1KBI22u000897; Thu, 20 Feb 2014 13:18:02 +0200 Received: from IL-EX10.ad.checkpoint.com ([169.254.2.228]) by DAG-EX10.ad.checkpoint.com ([169.254.3.228]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 13:18:02 +0200 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] WGLC for draft-ietf-websec-key-pinning-10 Thread-Index: AQHPI+iHfegE/LNl5EGrsl68Mjm8oZqxcgWAgAuo4ACAANabAA== Date: Thu, 20 Feb 2014 11:18:01 +0000 Message-ID: References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.94] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <9E5B11BD2479794C88F3681AF8CB0EF9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/OMtxiHwjl4xTOKxH-jfTzcB_00s Cc: IETF WebSec WG Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Thu, 20 Feb 2014 11:18:12 -0000 On Feb 20, 2014, at 12:29 AM, Chris Palmer wrote: >=20 >> Section 2.5. >> Section 2.4 says that future versions may add new algorithms. So we shou= ld >> be prepared for new algorithms. Section 2.5 says "For forward compatibil= ity, >> the UA MUST ignore any unrecognized Public-Key-Pins header directives, w= hile >> still processing those directives it does recognize." So suppose the UA= got >> the following header: >>=20 >> Public-Key-Pins: max-age=3D2592000; >> pin-sha4-256=3D"E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=3D"; >> pin-sha4-256=3D"LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=3D" >>=20 >> Not having support for SHA4, it can't validate or use these pins. That i= s >> fine when the server keys are not yet pinned. Now suppose that the serve= r is >> pinned (because previously it expressed HPKP with a SHA2-256. Does the U= A >> (a) ignore it, keeping the old pin, or (b) treat this as unpinning? Eit= her >> way, where does it say so? >=20 > I don't think the text currently handles this case. And, I don't know > which of (a) or (b) is preferable. >=20 > It's a bit of a pathological case; why would a site operator send such > a header, knowing as they do that the current version of HPKP > specifies only SHA-256 (i.e. SHA2-256)? >=20 > In future versions, in which we hypothetically add support for SHA4 > (or whatever future hash function), presumably we'd include some > language about this. But for now, any site operator doing this would > be making a mistake. I think we do need to specify how an implementation of *this* spec deals wi= th unknown hashes. Imagine that this technology came about 15 years ago, an= d that many websites had "pin-sha1" headers. Then in 2006 we realized that = SHA-1 was no longer considered secure, and wrote a new RFC with pin-SHA256 = (that was the new thing in 2005). Now it's 2014, and a site operator believ= es that everyone's browser supports the new standard, so he replaces the pi= n-sha1s with pin-sha256s. As it turns out, some browsers only started suppo= rting the new standard in 2009, and some people are using an unupdated brow= ser from 2008.=20 Back to the real world, we don't have to say how to handle pin-sha4 directi= ves, but we do have to specify how to handle pin directives that we don't r= ecognize. Section 2.5 says: For forward compatibility, the UA MUST ignore any unrecognized Public-Key-Pins header directives, while still processing those directives it does recognize. Section 2.1 specifies the directives max-age, Pins, includeSubDomains, and report-uri but future specifications and implementations might use additional directives. I guess "ignoring" is similar to omitting or filtering out, so my hypotheti= cal header from above reduces to: Public-Key-Pins: max-age=3D2592000 What do we do with this, (a) or (b), and where does it say so. BTW: I'm not= sure how servers can disable pinning. "max-age=3D0" is given as an example= , but reading section 2.5 strictly seems to suggest that even with max-age= =3D0 you need one valid pin from the certificate chain, and one valid pin n= ot from the certificate chain. This makes the above example non-valid, so i= t shouldn't be noted, but it's weird that you require pins to unpin. Thanks Yoav From nobody Fri Feb 21 00:24:36 2014 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 B54411A0031 for ; Fri, 21 Feb 2014 00:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 uqejnm6-uZ-w for ; Fri, 21 Feb 2014 00:24:33 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 000B31A0009 for ; Fri, 21 Feb 2014 00:24:32 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so541461wib.1 for ; Fri, 21 Feb 2014 00:24:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=u/W/har1rKWfEsAYYdvSmKBgJXfMtwVWvCVBHz92icE=; b=JDjxInJrT/cuMb5oHC0sGDFRAYl1l5f2qvvN3nhdnz7bJJjcWt/azuLNtgVt5K5Q5z xZrfMaV5yVz5Dx6utjU1b7VNvLfVwIFoRojlNqSJSKraN9C/2RaLT/wVRlzGHacMowmP oUtaoY0TnXiQV7FXGOPKVgsbPsg9PjKp47NKvtKoHvW/sXawviocK/MjbBLmq4S+vDBX zkDsZLqhbRVX98cVZ9axKshzWIkZiop4WkQsQNlfCdhBNkjQdvDueskjeodhIrOgQE3w IelroFCn/CsOuJUfozyTo4vHAu4J1J25SWmPXd0uVgB4PJT2+n3zPJLOIa+bGeGkSaO7 t0/w== X-Gm-Message-State: ALoCoQkQO1pdTLavPkXEcOS87mJEUDrL/vIYbiJMUhZs6ek0Mk4ZHESVCD3T77UfRjVOxmpgh3XK MIME-Version: 1.0 X-Received: by 10.180.187.237 with SMTP id fv13mr2030100wic.26.1392971068662; Fri, 21 Feb 2014 00:24:28 -0800 (PST) Received: by 10.216.45.146 with HTTP; Fri, 21 Feb 2014 00:24:28 -0800 (PST) X-Originating-IP: [166.137.185.75] Date: Fri, 21 Feb 2014 00:24:28 -0800 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/EQvYQHg5mnVTDbG0XKk637hESTY Subject: [websec] Public-Key-Pins-Report-Only 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: Fri, 21 Feb 2014 08:24:34 -0000 Hi websec, How should HPKP's Public-Key-Pins-Report-Only header work? Does it only apply a check to the current TLS connection, or is the UA is expected to remember the pins and apply them to future connections? If the UA is expected to remember them, how do "Report-Only" pins interact with regular pins? Do they override each other or are Report-Only pins tracked separately, so that a browser might have a Report-Only pin and a "regular" pin for the same site? Trevor From nobody Fri Feb 21 12:49:27 2014 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 0D57C1A020F for ; Fri, 21 Feb 2014 12:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 sXfEViCCO4ke for ; Fri, 21 Feb 2014 12:49:14 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 78C9B1A01B6 for ; Fri, 21 Feb 2014 12:49:14 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=C7dihfRydYoe4htJHVgDgvAc+wtSAN/Zh2bBrf9kXe2uVwozzovorV1TNtrnh/IWXA12jPtONuCjamaIyiF1XCdWjl79aSuqE3afKU1SulHcahDoY65EVxo+Lyyg0Wx0us7L2GAeGPRaOQUeaHLNe8B9ygTxtr1NVoAIZHIWicI=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (2e40e8bc.skybroadband.com [46.64.232.188]) by www.gondrom.org (Postfix) with ESMTPSA id 03F6C15390014; Fri, 21 Feb 2014 21:49:07 +0100 (CET) Message-ID: <5307BBC3.9080505@gondrom.org> Date: Fri, 21 Feb 2014 20:49:07 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tom@ritter.vg, palmer@google.com References: <4613980CFC78314ABFD7F85CC302772121BB196F@DAG-EX10.ad.checkpoint.com> <7D003007-1B62-4365-8B0E-28647FBB21C8@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/_wGl0LNagen9eaLOlzgxuq3qhnQ Cc: websec@ietf.org Subject: Re: [websec] Pre-loaded pins vs dynamic pins 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: Fri, 21 Feb 2014 20:49:19 -0000 On 19/02/14 22:48, Tom Ritter wrote: > On 19 February 2014 16:14, Chris Palmer wrote: >> On Wed, Feb 19, 2014 at 12:09 PM, Yoav Nir wrote: >>> Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way. >> I don't object; I like that well enough. > Seconded/Thirded/Fourthed I agree. Thirded Cheers, Tobias > > -tom > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Fri Feb 21 12:58:51 2014 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 675901A0242 for ; Fri, 21 Feb 2014 12:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 U2ycvqnGuCvy for ; Fri, 21 Feb 2014 12:58:44 -0800 (PST) Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) by ietfa.amsl.com (Postfix) with ESMTP id 683381A01B6 for ; Fri, 21 Feb 2014 12:58:44 -0800 (PST) X-No-Relay: not in my network DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=MimczgskUEkUyylc5L3KAWlqOkitUg4wt0y3qVVGekCaBSnPlrbJvTnLyKgnsPyT2C3PalAZS4lHK8fm3RHwo4hPA/qevvw95k56vlVRhd5+vbnGvoZ3z+KDiXJj8Z+X1aSvwqr0iPN35TcUjvxFXdyOFYOqEMl5IX4BUdI2AxI=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.6] (2e40e8bc.skybroadband.com [46.64.232.188]) by www.gondrom.org (Postfix) with ESMTPSA id AFEAA15390014; Fri, 21 Feb 2014 21:58:37 +0100 (CET) Message-ID: <5307BDFD.7060009@gondrom.org> Date: Fri, 21 Feb 2014 20:58:37 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ynir@checkpoint.com, palmer@google.com References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/202HBJqddhZW6yXOr67jG-C0jZI Cc: websec@ietf.org Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Fri, 21 Feb 2014 20:58:47 -0000 On 20/02/14 11:18, Yoav Nir wrote: > On Feb 20, 2014, at 12:29 AM, Chris Palmer wrote: > >>> Section 2.5. >>> Section 2.4 says that future versions may add new algorithms. So we should >>> be prepared for new algorithms. Section 2.5 says "For forward compatibility, >>> the UA MUST ignore any unrecognized Public-Key-Pins header directives, while >>> still processing those directives it does recognize." So suppose the UA got >>> the following header: >>> >>> Public-Key-Pins: max-age=2592000; >>> pin-sha4-256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; >>> pin-sha4-256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" >>> >>> Not having support for SHA4, it can't validate or use these pins. That is >>> fine when the server keys are not yet pinned. Now suppose that the server is >>> pinned (because previously it expressed HPKP with a SHA2-256. Does the UA >>> (a) ignore it, keeping the old pin, or (b) treat this as unpinning? Either >>> way, where does it say so? >> I don't think the text currently handles this case. And, I don't know >> which of (a) or (b) is preferable. >> >> It's a bit of a pathological case; why would a site operator send such >> a header, knowing as they do that the current version of HPKP >> specifies only SHA-256 (i.e. SHA2-256)? >> >> In future versions, in which we hypothetically add support for SHA4 >> (or whatever future hash function), presumably we'd include some >> language about this. But for now, any site operator doing this would >> be making a mistake. > I think we do need to specify how an implementation of *this* spec deals with unknown hashes. Imagine that this technology came about 15 years ago, and that many websites had "pin-sha1" headers. Then in 2006 we realized that SHA-1 was no longer considered secure, and wrote a new RFC with pin-SHA256 (that was the new thing in 2005). Now it's 2014, and a site operator believes that everyone's browser supports the new standard, so he replaces the pin-sha1s with pin-sha256s. As it turns out, some browsers only started supporting the new standard in 2009, and some people are using an unupdated browser from 2008. > > Back to the real world, we don't have to say how to handle pin-sha4 directives, but we do have to specify how to handle pin directives that we don't recognize. Section 2.5 says: > For forward compatibility, the UA MUST ignore any unrecognized > Public-Key-Pins header directives, while still processing those > directives it does recognize. Section 2.1 specifies the directives > max-age, Pins, includeSubDomains, and report-uri but future > specifications and implementations might use additional directives. > > I guess "ignoring" is similar to omitting or filtering out, so my hypothetical header from above reduces to: > > Public-Key-Pins: max-age=2592000 > > What do we do with this, (a) or (b), and where does it say so. BTW: I'm not sure how servers can disable pinning. "max-age=0" is given as an example, but reading section 2.5 strictly seems to suggest that even with max-age=0 you need one valid pin from the certificate chain, and one valid pin not from the certificate chain. This makes the above example non-valid, so it shouldn't be noted, but it's weird that you require pins to unpin. in case of an unrecognised pin-shaX, scenario (a) would result in a potentially dangerous situation, that can brick the site, i.e. make it unavailable. If the new pin is ignored, i.e. not noted, that would mean the old pin would remain in place for the full period of time, even though maybe the new cert will be active soon and the old one no longer available. So I am afraid we probably need to entertain (b)? Best regards, Tobias > Thanks > > Yoav > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Sat Feb 22 10:49:22 2014 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 16DEB1A00BD for ; Sat, 22 Feb 2014 10:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 JD6q8E_EUSOy for ; Sat, 22 Feb 2014 10:49:18 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B42AD1A0074 for ; Sat, 22 Feb 2014 10:49:18 -0800 (PST) Received: from [192.168.13.153] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2734EF984 for ; Sat, 22 Feb 2014 13:49:12 -0500 (EST) Message-ID: <5308F126.7020308@fifthhorseman.net> Date: Sat, 22 Feb 2014 13:49:10 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: websec@ietf.org References: <20140206190106.28263.74604.idtracker@ietfa.amsl.com> <64C19E86-86C8-4817-A01B-F9F726096A6C@checkpoint.com> <5307BDFD.7060009@gondrom.org> In-Reply-To: <5307BDFD.7060009@gondrom.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dC5dfoEpEKns7CgaUBVchtFCfmIGCeeqS" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/HosYTG3eiIGYKmBDpnc5IvEiPiE Subject: Re: [websec] WGLC for draft-ietf-websec-key-pinning-10 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: Sat, 22 Feb 2014 18:49:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dC5dfoEpEKns7CgaUBVchtFCfmIGCeeqS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/21/2014 03:58 PM, Tobias Gondrom wrote: >> (a) ignore it, keeping the old pin, or (b) treat this as unpinning? > in case of an unrecognised pin-shaX, scenario (a) would result in a > potentially dangerous situation, that can brick the site, i.e. make it > unavailable. > If the new pin is ignored, i.e. not noted, that would mean the old pin > would remain in place for the full period of time, even though maybe th= e > new cert will be active soon and the old one no longer available. > So I am afraid we probably need to entertain (b)? I also think that (b) (unpinning) is the right answer here, considering the semantics of the decision. Consider it this way: * the site operator gets to decide what pins they issue, and what hash algorithms to use. * the site operator presumably has a rough idea of how many of their clients are using software that might not be able to handle new hash algorithms * the site operator also decides what security properties/strength they require of a given hash algorithm. If the site operator considers an older hash algorithm to be too weak to rely on, and a client only knows that hash algorithm, then the site operator asking that client to unpin (and perhaps acknowledge the lack of pinning to the user via whatever UI provides information about the pin) is the right thing to do. If a site operator considers the older hash algorithm to be weak but still acceptable as a pin for those that only know that hash algorithm, then they should include a matching pin with the older hash algorithm as well as their preferred hash algorithm. This raises a couple of suggestions for me: 0) if a site operator decides to use more than one hash algorithms in the future, do we require that they issue the same set of pins under each algorithm? So if i'm pinning keys X and Y and Z, and i'm using both pin-sha2-256 and pin-sha3-256, must i issue 6 pins? I think it's reasonable to say yes here, even if we don't have any other digests defined yet. Why would you want to pin different keys with different hash algorithms? 1) If a UA knows about two hashing algorithms, then the language in 2.6 is potentially problematic for visiting a site that provides pins using both hashing algorithms. In particular, checking the set intersection of all pins suggests that an attacker need only defeat the weakest hash. I suggest that when multiple hash algorithms are known to the UA, and it has pins for a given site under more than one hash algorithm, then it must look for the set intersection *per hash algorithm used by the site* and only proceed if all hash algorithms show a set intersection. This should raise the attacker's bar to the strongest of the set of hashes used, rather than the weakest. Regards, --dkg --dC5dfoEpEKns7CgaUBVchtFCfmIGCeeqS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTCPEmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcSekQAMrbMDTUGHohQVXCRncBgiTL LWtuPLQmE+aTSaGPD+LEX9+3iya0531d6Y3YqU9ZHNpDSOt3miJm8JImV3iOae5q i4YqGqprAQOVzQvmRTW8W4M+v9w5eCUigrAzuJnUry2BN/mqyEPhwgBCoYHfv4RG OJdIS+HwZCyIxWq3LxZh0VwC0H7XBUOv8j/5P2oZYKe1WKT66YSV58SOhQbGZ9ag 2M3FGbiRO/zg6GGZCovJVyz7qZGOzLqtdPwIMBd0wRZjqxhvTOCwXAUYLehsl267 rG4BLuVaX0DJiIUGe749cwtCsPMxe6aaC3yZsxDk4Nn6fyss+mKVFGLCeweRV5Vu r1nJHws2/QZJoaIPq+zOV1G9EXWRF3U0B+5SVgCcvPI4A0U2azKEs8J0t7rpSfAp zt0dWr1YS7vZI6s6MVKDBpnk4O8z9E12PzfXuHiMnV8JPvrVq0pJFgtnFMHq3hXX gBOmgXrqkJEX69YBUNGwoutaDjTdjxqK6FSlsTQeTZ4xM0hepIRjAQMJ24deByOW lXxaWjfZ8vAHug0D/++jerTUg1e0bowXYh2Kcf8KVcl1b4uoOfq8OIv+LKjAoRsL ewqBv5wA/bs7rYlCEI2+6apz73pbWYuB3n+yHwWUuDaSa5IvH/DV86hoxkX/6jQn u3fFvwaq/iLt+uTEnq8Q =S7C0 -----END PGP SIGNATURE----- --dC5dfoEpEKns7CgaUBVchtFCfmIGCeeqS-- From nobody Wed Feb 26 08:32:11 2014 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 A22B21A00B6 for ; Wed, 26 Feb 2014 08:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 f2ufcHvFvqdF for ; Wed, 26 Feb 2014 08:31:58 -0800 (PST) Received: from mail-we0-x242.google.com (mail-we0-x242.google.com [IPv6:2a00:1450:400c:c03::242]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE161A06B3 for ; Wed, 26 Feb 2014 08:31:54 -0800 (PST) Received: by mail-we0-f194.google.com with SMTP id u56so562774wes.5 for ; Wed, 26 Feb 2014 08:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Nhv16YjJxgPru94JnrTxbGFQfNs/ZCl9uU8Enc0kkFI=; b=Ddf3ILgYF9Ecnqpfjpc3U51Jt6pDeuwhEmeJpZLxDpRNTdukBqQUlkFkByqSoOmQsp Vnni74hPbxw1OMkwkXqokADnez+D9fGj52pf3bhWIlqZeJLV8bhm0kP+8gM5SeOOyr6Z z1+Uam+xtVMCGonuYXxuwRpupw947bkt4yQ5ufwWyKSN7WClOMbS4GCpe2GovAMlbWUa AzAKiZdYOcjdV7J7I8aZQyGcYTe5+5mtBG/+uDNck8cqKMShBTk32qyuqXzYH2fxsynX 0m8DemQUPy0FETnxueTGgFEpjL01ieFu8YpJdKgy5ODhmeb5Wz6ZxlJb00EGPUhv9psq +jfQ== X-Received: by 10.194.2.110 with SMTP id 14mr98458wjt.96.1393432312947; Wed, 26 Feb 2014 08:31:52 -0800 (PST) Received: from [172.24.249.113] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id di9sm6861798wid.6.2014.02.26.08.31.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Feb 2014 08:31:52 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> Date: Wed, 26 Feb 2014 18:30:39 +0200 To: IETF WebSec WG Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/SJQWgx_cdJg0BLm3rUSXHalOLI0 Subject: [websec] Public-Key-Pins-Report-Only - attempt at summary 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, 26 Feb 2014 16:32:03 -0000 Hi I think all the issues raised during this WGLC have been (I think) = addressed (and correct me on another thread if I=92ve missed something), = with the exception of some issues with the Report-Only header. First issue was the interaction between PKP and PKPRO if both are = present. Current text ([1]) says =93If a Host sets both the = Public-Key-Pins header and the Public-Key-Pins-Report-Only header, the = UA MUST NOT enforce Pin Validation=94. This was objected to by some = ([2[), as it doesn=92t follow the CSP model. Chris suggested alternative = text that allows them both ([3]), where PKP is enforced, and PKPRO is = only noted and reported. There were no objections to this, except that = Tom corrected a typo. Can we consider this resolved? Then Trevor brought up another issue ([4]). He asked whether the UA = actually notes PKPRO pins or just reports on them. Nobody has responded = yet, but I think that=92s a good point. Is there any value to noting = PKPRO for, say, a month, and then reporting after two weeks that the = current certificates do not match? When I imagine how someone would use = PKPRO, I guess they generate a pins string, issue them as PKPRO, and if = no reports arrive for, say, 7 days, they are moved into =93production=94, = which is the regular PKP. Suppose the pins in PKPRO do generate reports, = I guess the administrator checks the reports, fixes whatever is wrong, = and posts the good pins as PKPRO again. Does it make sense to keep = receiving reports for the old pins? OTOH if we accept the non-noting = idea, then the max-age directive makes no sense and should be omitted. = As there has been no discussion yet, we need to consider this a bit.=20 Please do. Yoav & Tobias [1] = http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.1.3 [2] http://www.ietf.org/mail-archive/web/websec/current/msg02001.html [3] http://www.ietf.org/mail-archive/web/websec/current/msg02026.html [4] http://www.ietf.org/mail-archive/web/websec/current/msg02030.html= From nobody Wed Feb 26 09:20:56 2014 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 1B71B1A0734 for ; Wed, 26 Feb 2014 09:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 D9H7sAU_YjK5 for ; Wed, 26 Feb 2014 09:20:45 -0800 (PST) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0581A0739 for ; Wed, 26 Feb 2014 09:20:36 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so1861472wes.23 for ; Wed, 26 Feb 2014 09:20:35 -0800 (PST) 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=4VIJtfFazni/HzOXRIm82glafIp9oCHsFLPq8MWyigE=; b=V9o6SDL7Ff5dmprXiqB23afslsrAzg4tGMxGXoLMFYe1AMY3uOxqBxgWdMNhxEGVXL anodffNA4i1nQ5//BphDHgadG0pS7unIwE1dVBI1V4bYejSOFy3Z724BgtYcDGLxwesa vSnlVh3af/7Ks4TMRZia7CUKPC1tR8vtGe8k2ED0POtEiwMfvM6YUe3bSlIe1cXip4Wo 9vUc7U8OorkehYpET1Ja8jmnqIOxiarucr9AKaJhjtmsID6Y3x+6162y971WUz4nxSAj xKqN0RGiUDazRy4PjizBhlLGE5IyCRkJnf2DWa3FrqHJttcf6tQucvpLxcUx2aTalDeK vaow== X-Gm-Message-State: ALoCoQmXsIpPGYhwvTY45Q+g/YHk7GRHk5Me/7UkBLRrp5RRYFZPkdhyadfvv+jAr7GW0XaIG2q8 MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr8820675wiw.56.1393435234679; Wed, 26 Feb 2014 09:20:34 -0800 (PST) Received: by 10.216.45.146 with HTTP; Wed, 26 Feb 2014 09:20:34 -0800 (PST) X-Originating-IP: [184.23.29.222] In-Reply-To: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> Date: Wed, 26 Feb 2014 09:20:34 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d043c801e2e573004f3526ca2 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/zomwwbzSSg5h_UTyV9VUmA-8sxg Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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, 26 Feb 2014 17:20:51 -0000 --f46d043c801e2e573004f3526ca2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 26, 2014 at 8:30 AM, Yoav Nir wrote: > Hi > > I think all the issues raised during this WGLC have been (I think) > addressed (and correct me on another thread if I've missed something), with > the exception of some issues with the Report-Only header. > I don't know whether the recently-discussed issues are addressed, as we haven't seen a new draft. Many of the issues I raised in July and November are still outstanding: http://www.ietf.org/mail-archive/web/websec/current/msg02011.html http://www.ietf.org/mail-archive/web/websec/current/msg01956.html http://www.ietf.org/mail-archive/web/websec/current/msg01692.html I'll bring them up again once there's a new draft. > First issue was the interaction between PKP and PKPRO if both are present. > Current text ([1]) says "If a Host sets both the Public-Key-Pins header and > the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin > Validation". This was objected to by some ([2[), as it doesn't follow the > CSP model. Chris suggested alternative text that allows them both ([3]), > where PKP is enforced, and PKPRO is only noted and reported. There were no > objections to this, except that Tom corrected a typo. Can we consider this > resolved? > No, because this is linked to the question about how PKP-RO works, which we don't have an answer to: http://www.ietf.org/mail-archive/web/websec/current/msg02030.html > Then Trevor brought up another issue ([4]). He asked whether the UA > actually notes PKPRO pins or just reports on them. Nobody has responded > yet, but I think that's a good point. Is there any value to noting PKPRO > for, say, a month, and then reporting after two weeks that the current > certificates do not match? When I imagine how someone would use PKPRO, I > guess they generate a pins string, issue them as PKPRO, and if no reports > arrive for, say, 7 days, they are moved into "production", which is the > regular PKP. Suppose the pins in PKPRO do generate reports, I guess the > administrator checks the reports, fixes whatever is wrong, and posts the > good pins as PKPRO again. Does it make sense to keep receiving reports for > the old pins? OTOH if we accept the non-noting idea, then the max-age > directive makes no sense and should be omitted. As there has been no > discussion yet, we need to consider this a bit. > The issue is not just old pins, it's whether the browser is expected to the apply the PKP-RO check to other connections besides the current one, and if so, how these two different types of pins co-exist, whether they overwrite each other, etc. Trevor --f46d043c801e2e573004f3526ca2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 26, 2014 at 8:30 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi

I think all the issues raised during this WGLC have been (I think) addresse= d (and correct me on another thread if I’ve missed something), with t= he exception of some issues with the Report-Only header.

I don't know whether the recently-discussed issues are a= ddressed, as we haven't seen a new draft. 

Many of the issues I raised in July and November are still outstanding:


I'll bring them up again once the= re's a new draft.

 
First issue was the interaction between PKP and PKPRO if both are present. = Current text ([1]) says “If a Host sets both the Public-Key-Pins head= er and the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin = Validation”.  This was objected to by some ([2[), as it doesn&rs= quo;t follow the CSP model. Chris suggested alternative text that allows th= em both ([3]), where PKP is enforced, and PKPRO is only noted and reported.= There were no objections to this, except that Tom corrected a typo. Can we= consider this resolved?

No, because this is linked to the question= about how PKP-RO works, which we don't have an answer to:

 
Then Trevor brought up another issue ([4]). He asked whether the UA actuall= y notes PKPRO pins or just reports on them. Nobody has responded yet, but I= think that’s a good point. Is there any value to noting PKPRO for, s= ay, a month, and then reporting after two weeks that the current certificat= es do not match?  When I imagine how someone would use PKPRO, I guess = they generate a pins string, issue them as PKPRO, and if no reports arrive = for, say, 7 days, they are moved into “production”, which is th= e regular PKP. Suppose the pins in PKPRO do generate reports, I guess the a= dministrator checks the reports, fixes whatever is wrong, and posts the goo= d pins as PKPRO again. Does it make sense to keep receiving reports for the= old pins?  OTOH if we accept the non-noting idea, then the max-age di= rective makes no sense and should be omitted.  As there has been no di= scussion yet, we need to consider this a bit.

The issue is not just old pins, it's w= hether the browser is expected to the apply the PKP-RO check to other conne= ctions besides the current one, and if so, how these two different types of= pins co-exist, whether they overwrite each other, etc.


Trevor
--f46d043c801e2e573004f3526ca2-- From nobody Wed Feb 26 13:44:32 2014 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 961D11A02C3 for ; Wed, 26 Feb 2014 13:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 5I5Xj6RL6uGI for ; Wed, 26 Feb 2014 13:44:21 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id BD64F1A015E for ; Wed, 26 Feb 2014 13:44:21 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 8567677807E; Wed, 26 Feb 2014 13:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=3721knUTsVHHnK1Yx95lsVjXn64=; b=Po/oZiV+Adist/POo ypEGz1xQRykYfZjJv+M2afajMtaFAz1PTUXzsF9FvqJAK+sXHxn4ElJ3M3EGlUoP qBUofCFa5d7LeCdJWa5E86PtXK070INH72f35YWsgI4b5o+0nx38+9KyBFelVTnw vcZSDFbDzaKvTXJZV3fxYtDOYs= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id 016D677806E; Wed, 26 Feb 2014 13:44:19 -0800 (PST) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 26 Feb 2014 13:44:20 -0800 Message-ID: <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> In-Reply-To: References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> Date: Wed, 26 Feb 2014 13:44:20 -0800 From: "Ryan Sleevi" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/hzjXOyDPWhaT_5aWFJdKe6O-zw8 Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:44:24 -0000 On Wed, February 26, 2014 9:20 am, Trevor Perrin wrote: > On Wed, Feb 26, 2014 at 8:30 AM, Yoav Nir wrote: > > > Hi > > > > I think all the issues raised during this WGLC have been (I think) > > addressed (and correct me on another thread if I've missed something)= , > > with > > the exception of some issues with the Report-Only header. > > > > I don't know whether the recently-discussed issues are addressed, as w= e > haven't seen a new draft. > > Many of the issues I raised in July and November are still outstanding= : > > http://www.ietf.org/mail-archive/web/websec/current/msg02011.html > http://www.ietf.org/mail-archive/web/websec/current/msg01956.html > http://www.ietf.org/mail-archive/web/websec/current/msg01692.html > > I'll bring them up again once there's a new draft. If there are outstanding issues, we definitely want to be tracking them i= n the issue tracker. The threads you link to include several issues that should be resolved now. While I appreciate you linking to them, it would be helpful to make sure what you feel is outstanding is properly noted. > > > > > First issue was the interaction between PKP and PKPRO if both are > > present. > > Current text ([1]) says "If a Host sets both the Public-Key-Pins head= er > > and > > the Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin > > Validation". This was objected to by some ([2[), as it doesn't follo= w > > the > > CSP model. Chris suggested alternative text that allows them both ([3= ]), > > where PKP is enforced, and PKPRO is only noted and reported. There we= re > > no > > objections to this, except that Tom corrected a typo. Can we consider > > this > > resolved? > > > > No, because this is linked to the question about how PKP-RO works, whi= ch > we > don't have an answer to: > > http://www.ietf.org/mail-archive/web/websec/current/msg02030.html > > > > > Then Trevor brought up another issue ([4]). He asked whether the UA > > actually notes PKPRO pins or just reports on them. Nobody has respond= ed > > yet, but I think that's a good point. Is there any value to noting PK= PRO > > for, say, a month, and then reporting after two weeks that the curren= t > > certificates do not match? When I imagine how someone would use PKPR= O, > > I > > guess they generate a pins string, issue them as PKPRO, and if no > > reports > > arrive for, say, 7 days, they are moved into "production", which is t= he > > regular PKP. Suppose the pins in PKPRO do generate reports, I guess t= he > > administrator checks the reports, fixes whatever is wrong, and posts = the > > good pins as PKPRO again. Does it make sense to keep receiving report= s > > for > > the old pins? OTOH if we accept the non-noting idea, then the max-ag= e > > directive makes no sense and should be omitted. As there has been no > > discussion yet, we need to consider this a bit. > > > > The issue is not just old pins, it's whether the browser is expected t= o > the > apply the PKP-RO check to other connections besides the current one, a= nd > if > so, how these two different types of pins co-exist, whether they overw= rite > each other, etc. In attempt to resolve your outstanding issue(s) with PKP-RO, I want to first ensure that this proposal makes sense. If we're in agreement, we ca= n work on adding it to the next draft. PKP - Persistently recorded - Expires based on max-age - Causes all subsequent connections since 'noting' fails - Note that this is somewhat ambiguous within a UA that has multiple simultaneous connections, and for which header parsing may happen at any arbitrary time. - _HOWEVER_, I think this is best left up to implementations, since the external effects are consistent with how the server/service sets up resource fetching. PKP-RO - Not persistent - Applies only to the _single_ transport connection - Because HTTP connections MAY be kept-alive or re-used, to further qua= lify - Is evaluated upon receipt of the header, for the response it's included in. This means that if an HTTPS server sends PKP-RO header, then performs a TLS renegotiation that changes certificates in a way that violates the -RO, _NO_ report is sent. If the connection is used for another HTTP request, and -RO is sent, then the policy IS re-evaluated and a report is sent. Clarify that PKP-RO does _not_ affect the overall security state of the resource fetch. Specifically, it does NOT cause the connection to be closed with error. UAs MAY choose to also notify the user on -RO failures= , or MAY NOT - it's up to the implementation. Example of "notification" may include something as simple as logging to the developer console. Cheers, Ryan From nobody Wed Feb 26 15:05:29 2014 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 5D40E1A0868 for ; Wed, 26 Feb 2014 15:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 JhlDYJZXzBVC for ; Wed, 26 Feb 2014 15:05:20 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id B24851A0880 for ; Wed, 26 Feb 2014 15:05:18 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p61so2268554wes.10 for ; Wed, 26 Feb 2014 15:05:17 -0800 (PST) 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=XSy0aeJxqVkzkS1DbITMIGuA9BZcd6op4ARJtbR2w2E=; b=QIRGlrnuUVFv1NZnOhXD2B5q4648AVxBm7Imzbua0G/9uShas6L/B7j2Il4NKqEG2l TErPWALgeIsGQ/ZkJMr1hOvjluXUsbt4HmdyWwhkNxlv7YZkBCMA/8l9ScFhoVjBokKn sA2oyXD0qXXWqp4z8WothHOzfFkzEVqibSk/lbcyAmAKSee6p9gkNG1IXLTsdM/YluyS TFpO/02HJwXU/z1afMipk5iTBPXpApEUz2r8t/k8xGtrqJhLZNyzehHydyfe4jLADL8W MCjBHY2PxLfwoS3CscGlH16yV0I7mlkGrcacq+zpzSuQUaf4l2xcW8y/FjabcxeqP8Du 8sCA== X-Gm-Message-State: ALoCoQk1AX5ZA+LfODf6fwefJh4k71SELG1LM6fBWNr4wKX9D+JnMgkfgPxPFMSE9EWOtaNgXYVO MIME-Version: 1.0 X-Received: by 10.194.234.106 with SMTP id ud10mr4779746wjc.0.1393455911660; Wed, 26 Feb 2014 15:05:11 -0800 (PST) Received: by 10.216.45.146 with HTTP; Wed, 26 Feb 2014 15:05:11 -0800 (PST) X-Originating-IP: [184.23.29.222] In-Reply-To: <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> Date: Wed, 26 Feb 2014 15:05:11 -0800 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: multipart/alternative; boundary=089e01494078a0041204f3573c50 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/B0PtR3ffuG8Wr1q2ps94u1ajwrg Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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, 26 Feb 2014 23:05:25 -0000 --089e01494078a0041204f3573c50 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 26, 2014 at 1:44 PM, Ryan Sleevi wrote: > > In attempt to resolve your outstanding issue(s) with PKP-RO, I want to > first ensure that this proposal makes sense. If we're in agreement, we can > work on adding it to the next draft. > > PKP > - Persistently recorded > - Expires based on max-age > - Causes all subsequent connections since 'noting' fails > - Note that this is somewhat ambiguous within a UA that has multiple > simultaneous connections, and for which header parsing may happen at > any arbitrary time. > - _HOWEVER_, I think this is best left up to implementations, since > the external effects are consistent with how the server/service sets > up resource fetching. > > PKP-RO > - Not persistent > - Applies only to the _single_ transport connection > - Because HTTP connections MAY be kept-alive or re-used, to further > qualify > - Is evaluated upon receipt of the header, for the response it's > included in. > That's the simpler of the options. It means PKP-RO only tests whether the browser builds a chain you expect at one moment in time. It doesn't test whether the site is serving the correct certs for different URLs (e.g. includeSubdomains), so it's not a thorough test (i.e. the lack of reports doesn't provide much confidence that the PKP header is safe). It also doesn't have any security value. I don't hugely object to this, but given its limitations I'm not sure it's worth the effort. Curious what other people think. Trevor --089e01494078a0041204f3573c50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 26, 2014 at 1:44 PM, Ryan Sleevi <ryan-ietfhasmat@sl= eevi.com> wrote:

In attempt to resolve your outst= anding issue(s) with PKP-RO, I want to
first ensure that this proposal makes sense. If we're in agreement, we = can
work on adding it to the next draft.

PKP
=A0 - Persistently recorded
=A0 - Expires based on max-age
=A0 - Causes all subsequent connections since 'noting' fails
=A0 =A0 - Note that this is somewhat ambiguous within a UA that has multipl= e
simultaneous connections, and for which header parsing may happen at
any arbitrary time.
=A0 =A0 - _HOWEVER_, I think this is best left up to implementations, since=
the external effects are consistent with how the server/service sets
up resource fetching.

PKP-RO
=A0 - Not persistent
=A0 - Applies only to the _single_ transport connection
=A0 - Because HTTP connections MAY be kept-alive or re-used, to further qua= lify
=A0 =A0 - Is evaluated upon receipt of the header, for the response it'= s
included in.


That&#= 39;s the simpler of the options.

It means PKP-RO o= nly tests whether the browser builds a chain you expect at one moment in ti= me. =A0It doesn't test whether the site is serving the correct certs fo= r different URLs (e.g. includeSubdomains), so it's not a thorough test = (i.e. the lack of reports doesn't provide much confidence that the PKP = header is safe).
=A0=A0
It also doesn't have any security value.

I don't hugely object to this, but given its limitatio= ns I'm not sure it's worth the effort.

Cur= ious what other people think.


Trevor

<= /div>
--089e01494078a0041204f3573c50-- From nobody Thu Feb 27 01:44:44 2014 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 2FFA81A07DE for ; Thu, 27 Feb 2014 01:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YlJm8PCybSN0 for ; Thu, 27 Feb 2014 01:44:41 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0480B1A0178 for ; Thu, 27 Feb 2014 01:44:40 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id k10so1624408eaj.26 for ; Thu, 27 Feb 2014 01:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=85eLnS+iXRYL3T+V0dq7nPyffPUDcjC17FMN+XY2mxU=; b=IpgOZLM6+RfvDUPLBDKL+x15N5RFlaQsZNmt/g+b0i3fwGo3vzQgU3FUjvP46CcJ8L B6s9vOUGw5FB0zGwIds0zkrylGony6y20QNBvKdelTlYCVnbL1hsZZk+xSP/19ptP1bq c4u22hYqD/8jG/KTCY4e/r2YWkqsu/7lva/IA0FGqF1a9ZbQl34WUYV8LtSVJsavgxAw KWxT4yqK05J1n02xSe9PCPQBp6KcXdL40NpD1MeLo9IzC/OBIn7t9wQszd7Xs8PwnvkZ WyQQqo1np8Zxv+Ul6nUXji2GjlKqyV/94GMbSAHmADU5ppd0FJEh7Uf6twqEYjUYAZqw o4Tg== X-Received: by 10.14.179.129 with SMTP id h1mr12819367eem.26.1393494279086; Thu, 27 Feb 2014 01:44:39 -0800 (PST) Received: from [172.24.249.113] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id a2sm14791998eem.18.2014.02.27.01.44.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 01:44:38 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> Date: Thu, 27 Feb 2014 11:44:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> To: ryan-ietfhasmat@sleevi.com X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/4dOf7CiUOfY3jeFb0Ug2ITWIs68 Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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: Thu, 27 Feb 2014 09:44:43 -0000 On Feb 26, 2014, at 11:44 PM, Ryan Sleevi = wrote: >>=20 >> The issue is not just old pins, it's whether the browser is expected = to >> the >> apply the PKP-RO check to other connections besides the current one, = and >> if >> so, how these two different types of pins co-exist, whether they = overwrite >> each other, etc. >=20 > In attempt to resolve your outstanding issue(s) with PKP-RO, I want to > first ensure that this proposal makes sense. If we're in agreement, we = can > work on adding it to the next draft. >=20 > PKP > - Persistently recorded > - Expires based on max-age > - Causes all subsequent connections since 'noting' fails > - Note that this is somewhat ambiguous within a UA that has = multiple > simultaneous connections, and for which header parsing may happen at > any arbitrary time. > - _HOWEVER_, I think this is best left up to implementations, since > the external effects are consistent with how the server/service sets > up resource fetching. >=20 > PKP-RO > - Not persistent > - Applies only to the _single_ transport connection > - Because HTTP connections MAY be kept-alive or re-used, to further = qualify > - Is evaluated upon receipt of the header, for the response it's > included in. >=20 > This means that if an HTTPS server sends PKP-RO header, then performs = a > TLS renegotiation that changes certificates in a way that violates the > -RO, _NO_ report is sent. If the connection is used for another HTTP > request, and -RO is sent, then the policy IS re-evaluated and a report = is > sent. >=20 > Clarify that PKP-RO does _not_ affect the overall security state of = the > resource fetch. Specifically, it does NOT cause the connection to be > closed with error. UAs MAY choose to also notify the user on -RO = failures, > or MAY NOT - it's up to the implementation. Example of "notification" = may > include something as simple as logging to the developer console. I (with no hats) am very much in favor of this change. It makes sense = for the way I think this will be used. If I were administrating a web = server and wanted to use PKP, I would generate the PKP string and = install it as PKP-RO for a few days. If no reports came in, it would be = ready for production. I am not concerned about the renegotiation issue.=20= [with chair hat] if others feel differently, please speak up now. Yoav From nobody Thu Feb 27 01:51:29 2014 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 3D39C1A0173 for ; Thu, 27 Feb 2014 01:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 MJidNV-x0-74 for ; Thu, 27 Feb 2014 01:51:25 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 666C91A0149 for ; Thu, 27 Feb 2014 01:51:25 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id x13so2647859wgg.13 for ; Thu, 27 Feb 2014 01:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0ql2XqEgZjuJnHWQWMgHpo8e66nnSmX1Xu+FPMhzqP0=; b=XwDq39fkTrA3EavmDuevqDifbrqTrDFKSQhudn/DLFKj5JUz1vtnqwoE3XJLh5+7U+ BFVMBA23Op5Spy+XlwXIHjGoiRsYO+FJrWsZlJqZgWnENOWRateCFAjirtX702lcyehb 7Faw1WnbbeoiU8gIIrGMHhFXjr0AdXU0CIsuHV1IwaOMf4z9tRalIG2YgN1wKPw1/FFL Xv5z1bSRsvr2G4B/UQHbaifceDadqRYoGpqARr7pOpYMm47XFKtU64R7CsuGCmw3QEX3 7ee6Je9wh+doIml2JqoVJfVjbwo3CfZu0bpVtGaHLOUMIJoiFfnGX18W5yIfhZkG71B0 WSDg== X-Received: by 10.180.189.169 with SMTP id gj9mr8676499wic.17.1393494683498; Thu, 27 Feb 2014 01:51:23 -0800 (PST) Received: from [172.24.249.113] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id de3sm9721893wjb.8.2014.02.27.01.51.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 01:51:23 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9FB76FC4-D5A6-4650-916A-8ABD6F3310B0" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Thu, 27 Feb 2014 11:51:21 +0200 Message-Id: References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> To: Trevor Perrin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/yzVhxBcc98Xz9fZ-nr_m6ktmw8g Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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: Thu, 27 Feb 2014 09:51:27 -0000 --Apple-Mail=_9FB76FC4-D5A6-4650-916A-8ABD6F3310B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 27, 2014, at 1:05 AM, Trevor Perrin wrote: >=20 > On Wed, Feb 26, 2014 at 1:44 PM, Ryan Sleevi = wrote: >=20 > In attempt to resolve your outstanding issue(s) with PKP-RO, I want to > first ensure that this proposal makes sense. If we're in agreement, we = can > work on adding it to the next draft. >=20 > PKP > - Persistently recorded > - Expires based on max-age > - Causes all subsequent connections since 'noting' fails > - Note that this is somewhat ambiguous within a UA that has = multiple > simultaneous connections, and for which header parsing may happen at > any arbitrary time. > - _HOWEVER_, I think this is best left up to implementations, = since > the external effects are consistent with how the server/service sets > up resource fetching. >=20 > PKP-RO > - Not persistent > - Applies only to the _single_ transport connection > - Because HTTP connections MAY be kept-alive or re-used, to further = qualify > - Is evaluated upon receipt of the header, for the response it's > included in. >=20 >=20 > That's the simpler of the options. >=20 > It means PKP-RO only tests whether the browser builds a chain you = expect at one moment in time. It doesn't test whether the site is = serving the correct certs for different URLs (e.g. includeSubdomains), = so it's not a thorough test (i.e. the lack of reports doesn't provide = much confidence that the PKP header is safe). > =20 > It also doesn't have any security value. >=20 > I don't hugely object to this, but given its limitations I'm not sure = it's worth the effort. >=20 > Curious what other people think. Not much for security, because anyone who can mess with the certificates = that you=92re seeing can also mess with HTTP headers. But it does = provide a good mechanism for the administrator to avoid shooting himself = in the foot.=20 For example, if the administrator wants to use the pin-sha4 directive = from the other thread and one of the browsers and some browsers doesn=92t = support this directive, then having the SHA-4 pins in PKP-RO for a few = days will generate some reports, and the administrator might decide that = it=92s not yet time to move to SHA-4. Another example, if the administrator calculated the has wrong (like = hashing all the certificate rather than SPKI) they will also get = reports.=20 Unfortunately is doesn=92t help with the issue of replacing the = certificate with one whose chain is not covered by the pins - that=92s = the one that bricks your site. PKP-RO does not help this, but it still = has some value. Yoav --Apple-Mail=_9FB76FC4-D5A6-4650-916A-8ABD6F3310B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Feb 27, 2014, at 1:05 AM, Trevor = Perrin <trevp@trevp.net> = wrote:


On Wed, Feb 26, 2014 at 1:44 PM, Ryan Sleevi <ryan-ietfhasmat@sleevi.com> wrote:

In attempt to = resolve your outstanding issue(s) with PKP-RO, I want to
first ensure that this proposal makes sense. If we're in agreement, we = can
work on adding it to the next draft.

PKP
  - Persistently recorded
  - Expires based on max-age
  - Causes all subsequent connections since 'noting' fails
    - Note that this is somewhat ambiguous within a UA that = has multiple
simultaneous connections, and for which header parsing may happen at
any arbitrary time.
    - _HOWEVER_, I think this is best left up to = implementations, since
the external effects are consistent with how the server/service sets
up resource fetching.

PKP-RO
  - Not persistent
  - Applies only to the _single_ transport connection
  - Because HTTP connections MAY be kept-alive or re-used, to = further qualify
    - Is evaluated upon receipt of the header, for the = response it's
included = in.


That's the = simpler of the options.

It means PKP-RO only = tests whether the browser builds a chain you expect at one moment in = time.  It doesn't test whether the site is serving the correct = certs for different URLs (e.g. includeSubdomains), so it's not a = thorough test (i.e. the lack of reports doesn't provide much confidence = that the PKP header is safe).
  
It also doesn't have any security = value.

I don't hugely object to this, but given = its limitations I'm not sure it's worth the = effort.

Curious what other people think.

Not much for = security, because anyone who can mess with the certificates that you=92re = seeing can also mess with HTTP headers. But it does provide a good = mechanism for the administrator to avoid shooting himself in the = foot. 

For example, if the administrator = wants to use the pin-sha4 directive from the other thread and one of the = browsers and some browsers doesn=92t support this directive, then having = the SHA-4 pins in PKP-RO for a few days will generate some reports, and = the administrator might decide that it=92s not yet time to move to = SHA-4.

Another example, if the administrator = calculated the has wrong (like hashing all the certificate rather than = SPKI) they will also get = reports. 

Unfortunately is doesn=92t help = with the issue of replacing the certificate with one whose chain is not = covered by the pins - that=92s the one that bricks your site. PKP-RO = does not help this, but it still has some = value.

Yoav


= --Apple-Mail=_9FB76FC4-D5A6-4650-916A-8ABD6F3310B0-- From nobody Thu Feb 27 09:52:19 2014 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 14EFE1A00AE for ; Thu, 27 Feb 2014 09:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 p2iDpdzZeYU6 for ; Thu, 27 Feb 2014 09:52:15 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 386791A0074 for ; Thu, 27 Feb 2014 09:52:15 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id r20so1012517wiv.11 for ; Thu, 27 Feb 2014 09:52:13 -0800 (PST) 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=hJGOK2UXFPkcK6SUSG8mVfv0xhUmmnXa/KPlFlGKaFE=; b=l1rEfFFn3rUUUxwntvmtyECGWPVjxop3yeFe8uYHC91VtxoUCEPpTsu/aJyOFcsNK4 xKqegdx/W26skp1OmRpDTLOQD4beA/77BOiuaHDoaRUTF+ZbEIsGUOB8hnrbx6ve0uf+ QUO3DtMZRH6WsJUc2SyAFWQfuW6rNvtLuLPN7ho+qRAUXQEjtWN7amcSbG04PeJ2lKmM SOSUQrz+TSCb/PDGZBH47iscVy5/tr7vGzJcohUBu6t6uI8bkRvuudSUA8CslTK/kYwB NHw1QfCtq/2am9Wq48oTDJZ66SoJNz2346DMoOnSLf6KFOQNxxDSdNm8O7GziYJ9Ez+y 5IeQ== X-Gm-Message-State: ALoCoQlSlDi7PxZdCfi5f+0CoEf0x0Y0e0oXAXomRHpeRkxOhJ6EkJJApt832PPde+r2ABllO5RU MIME-Version: 1.0 X-Received: by 10.180.19.35 with SMTP id b3mr11245827wie.20.1393523533054; Thu, 27 Feb 2014 09:52:13 -0800 (PST) Received: by 10.216.45.146 with HTTP; Thu, 27 Feb 2014 09:52:12 -0800 (PST) X-Originating-IP: [184.23.29.222] In-Reply-To: <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> Date: Thu, 27 Feb 2014 09:52:12 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: multipart/alternative; boundary=bcaec53d5eb52c9a9604f366fb2a Archived-At: http://mailarchive.ietf.org/arch/msg/websec/0N2gbtBGXEc0BtvCJz-BenrfZdk Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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: Thu, 27 Feb 2014 17:52:18 -0000 --bcaec53d5eb52c9a9604f366fb2a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir wrote: > > > I (with no hats) am very much in favor of this change. It makes sense for > the way I think this will be used. If I were administrating a web server > and wanted to use PKP, I would generate the PKP string and install it as > PKP-RO for a few days. If no reports came in, it would be ready for > production. Not necessarily. This type of PKP-RO would *NOT* detect whether all your subdomains or load-balancers / front-end machines are correctly configured with the right certs. If people do what you suggest, they could easily get a false impression that they're ready to go live ("no reports - it must be good!"), and screw up their site. Trevor --bcaec53d5eb52c9a9604f366fb2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

I (with no hats) am very much in favor of this change. =A0It ma= kes sense for the way I think this will be used. If I were administrating a= web server and wanted to use PKP, I would generate the PKP string and inst= all it as PKP-RO for a few days. If no reports came in, it would be ready f= or production.

Not necessarily.

This typ= e of PKP-RO would *NOT* detect whether all your subdomains or load-balancer= s / front-end machines are correctly configured with the right certs.

If people do what you suggest, they could easily get a = false impression that they're ready to go live ("no reports - it m= ust be good!"), and screw up their site.


Trevor

--bcaec53d5eb52c9a9604f366fb2a-- From nobody Thu Feb 27 12:15:34 2014 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 2A2B61A0552 for ; Thu, 27 Feb 2014 12:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 bQCefqJ69K5P for ; Thu, 27 Feb 2014 12:15:30 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1001A01DD for ; Thu, 27 Feb 2014 12:15:29 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id A049F1DE071; Thu, 27 Feb 2014 12:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=peMKFkiNN5Bi4GHJLfugnFS77Oc=; b=gSHvCW4S5ET5a+Ajk 75uYabn0wTHdVvpSkgSCt3bTa6KwInhRhAqWySabChreXzn6lj2RloFz2yltCS8x RV59CpRFNgL8oq331irt1pnmOzHSaILy/lq0s00DR4CoDbJ1cpx++snf1UPvOSdj tr9CXTv2ghrwyYD9FoGymab+Z8= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id DD9BD1DE059; Thu, 27 Feb 2014 12:15:25 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 27 Feb 2014 12:15:27 -0800 Message-ID: <52e668d2acf894dbf5cc6efcd3d4510e.squirrel@webmail.dreamhost.com> In-Reply-To: References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> Date: Thu, 27 Feb 2014 12:15:27 -0800 From: "Ryan Sleevi" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/m_Ty4LNnl0adWq4oFZ6g747_Xfk Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 20:15:32 -0000 On Thu, February 27, 2014 9:52 am, Trevor Perrin wrote: > On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir wrote: > > > > > > I (with no hats) am very much in favor of this change. It makes sens= e > > for > > the way I think this will be used. If I were administrating a web ser= ver > > and wanted to use PKP, I would generate the PKP string and install it= as > > PKP-RO for a few days. If no reports came in, it would be ready for > > production. > > > Not necessarily. > > This type of PKP-RO would *NOT* detect whether all your subdomains or > load-balancers / front-end machines are correctly configured with the > right > certs. > > If people do what you suggest, they could easily get a false impressio= n > that they're ready to go live ("no reports - it must be good!"), and s= crew > up their site. > > > Trevor > Do you have any alternatives you would like to suggest? That might save a few feedback cycles. From nobody Thu Feb 27 12:31:05 2014 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 789CF1A067B for ; Thu, 27 Feb 2014 12:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 k2ZJ7lGg9CLy for ; Thu, 27 Feb 2014 12:31:02 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 589DC1A067F for ; Thu, 27 Feb 2014 12:31:02 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u56so3378673wes.31 for ; Thu, 27 Feb 2014 12:31:00 -0800 (PST) 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=EFFp6Y3mprX+bqCcb0h3taSnlXgwgYxDafrjlNf0/7g=; b=PRX1LOpSQz+JKJzGbDaUbs7FIJN7JVgFjo4AM5cZrgO2KqpfA9o6aZzWxUodLc4ZdN xTjy3+hsV31y/5oNq10jmgYkIgR/bL2BVDbRWnjVSrxPyza9wJDmHwA8Ia+qp7l5RZu/ axzVg1hsLJNaySdsHefFT5pNzRzUZ68V8pT7X8D2VpMSkAtBNrhprA1Y8q8N519EkiqG H3xSRk9m15JnZqkfrTEMbWQoZDq7YKcWJVIowLQyvQrRoZ8XI/XOD8U4fe743QsVOGIS dZWZT0a7KLXYD/jDWK3zMLK/IbE+PF7fWPwHW+A4A1B47tD9G8+gryssoI+qnRZSDemK QMsA== X-Gm-Message-State: ALoCoQmGvmf7HcPRsaHCkJzS8PRXfeCtjx9/ubGONdyYgdPuh2FEEmNdRiI8icJSb0Ilv1z4fFl1 MIME-Version: 1.0 X-Received: by 10.194.185.148 with SMTP id fc20mr9953648wjc.27.1393533060352; Thu, 27 Feb 2014 12:31:00 -0800 (PST) Received: by 10.216.45.146 with HTTP; Thu, 27 Feb 2014 12:31:00 -0800 (PST) X-Originating-IP: [184.23.29.222] In-Reply-To: <52e668d2acf894dbf5cc6efcd3d4510e.squirrel@webmail.dreamhost.com> References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> <52e668d2acf894dbf5cc6efcd3d4510e.squirrel@webmail.dreamhost.com> Date: Thu, 27 Feb 2014 12:31:00 -0800 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: multipart/alternative; boundary=047d7bdcab7c0ba1df04f36933ee Archived-At: http://mailarchive.ietf.org/arch/msg/websec/HU0iCs3MOjbvHRyfRz_hxBZ-yT4 Cc: IETF WebSec WG Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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: Thu, 27 Feb 2014 20:31:04 -0000 --047d7bdcab7c0ba1df04f36933ee Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 27, 2014 at 12:15 PM, Ryan Sleevi wrote: > On Thu, February 27, 2014 9:52 am, Trevor Perrin wrote: > > On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir wrote: > > > > > > > > > I (with no hats) am very much in favor of this change. It makes sense > > > for > > > the way I think this will be used. If I were administrating a web > server > > > and wanted to use PKP, I would generate the PKP string and install it > as > > > PKP-RO for a few days. If no reports came in, it would be ready for > > > production. > > > > > > Not necessarily. > > > > This type of PKP-RO would *NOT* detect whether all your subdomains or > > load-balancers / front-end machines are correctly configured with the > > right > > certs. > > > > If people do what you suggest, they could easily get a false impression > > that they're ready to go live ("no reports - it must be good!"), and > screw > > up their site. > > > > > > Trevor > > > > Do you have any alternatives you would like to suggest? That might save a > few feedback cycles. > The alternatives I see are: 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age, is applied to includeSubdomains), but only generates reports instead of hard fails. The browser would store PKP and PKP-RO pins in separate/parallel stores, for example setting max-age=0 for a PKP pin would not clear PKP-RO pins, and vice versa. 2) PKP-RO is removed from the spec. 3) Your suggestion - have PKP-RO implement a reduced set of PKP semantics (only check current connection). I'm not sure about the usefulness of that, and I worry site operators would be mislead by it. Trevor --047d7bdcab7c0ba1df04f36933ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 27, 2014 at 12:15 PM, Ryan Sleevi <ryan-ietfhasma= t@sleevi.com> wrote:
On T= hu, February 27, 2014 9:52 am, Trevor Perrin wrote:
> =A0On Thu, Feb 27, 2014 at 1:44 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> >
> >
> > I (with no hats) am very much in favor of this change. =A0It make= s sense
> > for
> > the way I think this will be used. If I were administrating a web= server
> > and wanted to use PKP, I would generate the PKP string and instal= l it as
> > PKP-RO for a few days. If no reports came in, it would be ready f= or
> > production.
>
>
> =A0Not necessarily.
>
> =A0This type of PKP-RO would *NOT* detect whether all your subdomains = or
> =A0load-balancers / front-end machines are correctly configured with t= he
> =A0right
> =A0certs.
>
> =A0If people do what you suggest, they could easily get a false impres= sion
> =A0that they're ready to go live ("no reports - it must be go= od!"), and screw
> =A0up their site.
>
>
> =A0Trevor
>

Do you have any alternatives you would like to suggest? That mi= ght save a
few feedback cycles.

The alternatives I= see are:

1) =A0PKP-RO implements the full PKP sem= antics (i.e. is stored for max-age, is applied to includeSubdomains), but o= nly generates reports instead of hard fails. =A0The browser would store PKP= and PKP-RO pins in separate/parallel stores, for example setting max-age= =3D0 for a PKP pin would not clear PKP-RO pins, and vice versa.

2) =A0PKP-RO is removed from the spec.

3) Your suggestion - have PKP-RO implement a reduced set of PKP se= mantics (only check current connection). =A0I'm not sure about the usef= ulness of that, and I worry site operators would be mislead by it.


Trevor

<= /div> --047d7bdcab7c0ba1df04f36933ee-- From nobody Thu Feb 27 13:08:00 2014 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 04C711A0698 for ; Thu, 27 Feb 2014 13:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 81Duk0nuxCiP for ; Thu, 27 Feb 2014 13:07:56 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DC5871A065B for ; Thu, 27 Feb 2014 13:07:55 -0800 (PST) Received: from [10.70.10.98] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E1B65F984 for ; Thu, 27 Feb 2014 16:07:52 -0500 (EST) Message-ID: <530FA91B.3060307@fifthhorseman.net> Date: Thu, 27 Feb 2014 16:07:39 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: IETF WebSec WG References: <0ED15743-A62A-4EFF-854F-BCB9E511E11F@gmail.com> <0a37408b7968140907d6e2589554ff91.squirrel@webmail.dreamhost.com> <2BA8C675-BB3E-4549-94FE-B0C11D112903@gmail.com> <52e668d2acf894dbf5cc6efcd3d4510e.squirrel@webmail.dreamhost.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SEpdPLTO0eh4wHB89pKqTI78T2dus3SC9" Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Ae1Ltozoig3nW1EL2P-8WKcDHM0 Subject: Re: [websec] Public-Key-Pins-Report-Only - attempt at summary 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: Thu, 27 Feb 2014 21:07:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SEpdPLTO0eh4wHB89pKqTI78T2dus3SC9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/27/2014 03:31 PM, Trevor Perrin wrote: > 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-ag= e, > is applied to includeSubdomains), but only generates reports instead of= > hard fails. The browser would store PKP and PKP-RO pins in > separate/parallel stores, for example setting max-age=3D0 for a PKP pin= would > not clear PKP-RO pins, and vice versa. >=20 > 2) PKP-RO is removed from the spec. >=20 > 3) Your suggestion - have PKP-RO implement a reduced set of PKP semanti= cs > (only check current connection). I'm not sure about the usefulness of > that, and I worry site operators would be mislead by it. As someone who sometimes helps to operate and plan the operation of web sites, i don't think the semantics of (3) are misleading, but they're not particularly confidence-inspiring either. What is the goal of PKP-RO? Is the goal to encourage adoption by giving site operators confidence in a proposed configuration or organizational workflow? The real footgunnery with PKP will come during key transition/rollover (or switching CAs), as clients who have cached pins cope with the changes. Using (3)-style PKP-RO to build confidence in an organizational workflow around this kind of transition event doesn't seem possible. --dkg --SEpdPLTO0eh4wHB89pKqTI78T2dus3SC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTD6kbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpczfEP/A0bkHMuw/qF7x0935U5GJg0 JRsCDqTGAlcRBkG9RoVG2xr6o2Iaa/oE7C2dWxVpzkBueeJ0nOprK+2hNIeLsXkT hHWEd3Ee9LbLoHUCTPfeaC700axMZ60rg3du8fi3TcJCHvyAbxsqz6QUcf/ga3dU ggMcQNycmbx8G1pfrUu3PzdL3dxeShi4m+W325NJ3yETVqI90477+wmIkmInJvbB cLN8Nrq7+v5qLFnUKoArP8ap9mAQorHm/MBq75zNxeNS5jXUM1NbtcNBv3qdXx5x j7VP8BIbiC2T45NAvG2cRlXZdG+AKnYXacFFhp/DaevH7WHgcRHHQkmA6aMcinMM DV9nbvrbj/tZ9nfGe3+eQjWv43QsJyasJ9u/nOiHYyWGh0jHlHNxEjjEnKuPpy60 hGGXcpPT2uDPJYBwTcgTrM8NwNMLqo/tqzjC7SDuxbjamAK0hgjBckB35Bq1WvML 8chKoviQGwjiae+tq2UD+n7eZ9huwE/XmXi2lkoc4dpk2TpNEbocw7unQID6J4Gj cRuMsye0IacBysoWY4sZRpDsiXM6amLx7mgYNmGOfV4RZzTEXRz/IIhZQiciT7mI e4X4s44f1dsQa7UD09yckvSI3PMwTkQb9kc7BOqhonl56jLy7iaVoM2C2hv6xKON CMDXQfeAarspYIBD/2Fm =KglO -----END PGP SIGNATURE----- --SEpdPLTO0eh4wHB89pKqTI78T2dus3SC9--