From nobody Wed Jun 4 17:49:02 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 DE9001A03DC for ; Wed, 4 Jun 2014 17:49:00 -0700 (PDT) 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 En3XWBzxyH9q for ; Wed, 4 Jun 2014 17:48:59 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A481A03AB for ; Wed, 4 Jun 2014 17:48:58 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so264245wgg.0 for ; Wed, 04 Jun 2014 17:48:51 -0700 (PDT) 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:cc :content-type; bh=LdvsMu6yYMvhhecQbzO2N9Gnh3opgpqkcJlcTvL1VIY=; b=Pfvd+dUS+vGcbqQjlX+rGV/KpAZ8Hv7HC5QQbmYZUnwPRyy7tC75n/5sLl6ix736cz EHSMjNIK/9Meei0/O3l17MFVS/cCHOgL86P3wCaVmljNYSwiEIkC64C3jNQwfACtYejN 3lHWwdt6HZcleqnhkfa6qJgLg9meMYoH8MnXKwoy4qXNzsoHVw1W/qPsKBnqe4i0BtaC aNlsNcItQNjjBbUnEvyMlT8zA43lSZi9h1maFZli/yWbfvU0AOHiGAwjvMLqY/M48JRt T3sFzFV8FyQ/q0oE/H0sU4EdOCuwAlnCwzGBTpPByMk85I5PI0K0OLBnvcZFh7DZ0ktd 5wZQ== X-Gm-Message-State: ALoCoQnV4ikKt2RmCLJugUdMXSQN1lnIXoUg7XnVelRlhu+0X+CzRvhRcHcC4N8eegRVcKuXNZzh MIME-Version: 1.0 X-Received: by 10.180.221.163 with SMTP id qf3mr10440245wic.56.1401929331695; Wed, 04 Jun 2014 17:48:51 -0700 (PDT) Received: by 10.216.155.7 with HTTP; Wed, 4 Jun 2014 17:48:51 -0700 (PDT) X-Originating-IP: [12.27.66.7] Date: Wed, 4 Jun 2014 17:48:51 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/yYnltxEdL97VMX43CUJlO1oMTHM Cc: IETF WebSec WG Subject: [websec] PKP-RO (was Re: I-D Action: draft-ietf-websec-key-pinning-12.txt) 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, 05 Jun 2014 00:49:01 -0000 Anyone have comments on below? Is there agreement on what PKP-RO should do yet? On Mon, May 19, 2014 at 11:28 PM, Trevor Perrin wrote: > On Tue, May 13, 2014 at 2:09 PM, Chris Palmer wrote: >> >> PKP vs. PKP-RO: >> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9 > > The new text about PKP-RO in 2.5 (quoted below) seems to say that a > PKP-RO header is only evaluated against the current connection, not > stored as a pin. I thought we decided the opposite (which is what I > think 2.3.2 is saying): > > 2.3.2 (existing text): > 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 the Pins > and directives given in the Public-Key-Pins-Report-Only header. > > 2.5 (new text): > The UA SHOULD NOT note any pins or other policy expressed in the PKP- > RO response header field. Trevor From nobody Thu Jun 12 17:23:57 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 6F0D61A0344; Thu, 12 Jun 2014 17:23:47 -0700 (PDT) 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 0g7yj0VH7VMa; Thu, 12 Jun 2014 17:23:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3B1A0328; Thu, 12 Jun 2014 17:23:35 -0700 (PDT) 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.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613002335.736.445.idtracker@ietfa.amsl.com> Date: Thu, 12 Jun 2014 17:23:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/56PirCCLF4wzS9NQ9HHll87NYJM Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-14.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: Fri, 13 Jun 2014 00:23:48 -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-14.txt Pages : 25 Date : 2014-06-12 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-14 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 nobody Mon Jun 16 16:03: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 3E5961A02B7 for ; Mon, 16 Jun 2014 16:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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.651, 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 PU9Y6HB-OLBf for ; Mon, 16 Jun 2014 16:03:15 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F861A02A8 for ; Mon, 16 Jun 2014 16:03:15 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hn18so3565402igb.5 for ; Mon, 16 Jun 2014 16:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qxpyOfvrTeUBwDMX5gwJRDdXF5NMlzE3vulecJgDxWU=; b=pEgByxZBLasM7A/agcCLTG3UtW+9PPT704/Vx+bLQmYQR0hDndkvZjNguHLDb2RbO9 XDIXfiGM5mDkzK+4DQfMayl4HSM5vvj1kIrZMVG83usF+9tnX1p4GOpAwkhVhqJTRor8 DPbyS6zUp45Fd8ASxNiiOkH24lLoz81MGlyhpkriGSGevnuiWSpOWf5Ai7PyZxwoNX3K 3NYhJ9nOkkvnuxZV9ioLo96VQgqRE9qlMgnuyFwB1+FP41NkLVf8IVCsRBDF/aMtLEXK xLhhQ69PlHbKuM3/b5bUWehk8XEoeH43zintZt3LM4u3kgSPvJPrJgTAoNZxVZmjSWvW N0Ag== 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=qxpyOfvrTeUBwDMX5gwJRDdXF5NMlzE3vulecJgDxWU=; b=LPEOOPfyuDpGCGS5C0Xi5N1ZzmucT0jV0B6491l1HhKJxsgrn6fNvk0gfDzlO0kC5I Q2PdAE4i+tEPkLL2XiO43jFqxStMO6WQowZxIdEphwxxbZUeb1xSDBEYiZWZyU/tJZTh 2H4BoYguVaszbsPS1P8Dsm8eF5fXVz+XOQA/5XhLnWVY2q+NvRe5ueQnRvgCtcZc8/fL xeYvFMi9m5tKmsdjJEesn6gktOyoGAoz3KcmdrP2E03FPdCH4mVyWkt2uOzw/aHSnNLZ VtqrMYp6x0+nFvgDTAQtn0s6YN1L0jQN+Adfx+8zFB6M4gcA7p/8vg93k9DiJ7lg1urS ZRfQ== X-Gm-Message-State: ALoCoQm5wH6lbqk1qfQVkt3rywLJAASJCh3M68DKUk7lKLlh5B+OXJv4n54QqD24FULuZr6xT1wH MIME-Version: 1.0 X-Received: by 10.42.148.67 with SMTP id q3mr23636678icv.5.1402959794719; Mon, 16 Jun 2014 16:03:14 -0700 (PDT) Received: by 10.64.137.40 with HTTP; Mon, 16 Jun 2014 16:03:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 16:03:14 -0700 Message-ID: From: Chris Palmer To: Igor Bukanov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/vND-RyyJ1ephCZa6SvrYmqNxOm0 Cc: IETF WebSec WG Subject: Re: [websec] key-pinning overrides and reporting 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: Mon, 16 Jun 2014 23:03:17 -0000 FYI, I added the proposed text: https://code.google.com/p/key-pinning-draft/source/detail?r=c30017eb14428df9d094a32ba46196245bdc5fe1 On Tue, May 27, 2014 at 11:03 PM, Igor Bukanov wrote: > This is somewhat related to the question if a website in general > should be allowed to know if the user uses non-approved certificate > that is installed on her device. This is important if one considers a > possibility of using social engineering to trick the user to install a > new certificate authority that allows to perform MTM attacks. I know > banks worry about that. > > However, allowing such knowledge to websites has a privacy > implications. Besides social engineering arguments are weak as a user > can be just as well tricked to install a special browser that skips > any ssl checks. So the proposed text change is good. > > On 27 May 2014 20:28, Chris Palmer wrote: >> On Thu, May 22, 2014 at 12:49 AM, Yoav Nir wrote: >> >>> Interesting question. IMO (no hats) the answer should be no. If the UA has disabled pin validation (as section 2.6 says it may) then it should not send reports either. >> >> Thanks for raising the question, Igor. I am inclined to agree with >> Yoav. Anyone else have thoughts? >> >> Is section 2.6 a good place to put a note about this issue? Proposed text: >> >> """ >> If Pin Validation is not in effect (e.g. because the user has elected >> to disable it, or because a presented certificate chain chains up to a >> locally-installed anchor), and if the server has set a report-uri in a >> PKP or PKP-RO header, the UA SHOULD NOT send any reports to the >> report-uri for the given certificate chain. >> """ From nobody Mon Jun 16 16:12: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 8256C1A02BE for ; Mon, 16 Jun 2014 16:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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.651, 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 hUelIeYuoSXM for ; Mon, 16 Jun 2014 16:12:41 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145AB1A02A8 for ; Mon, 16 Jun 2014 16:12:41 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y20so5663664ier.40 for ; Mon, 16 Jun 2014 16:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yx8+4pu8liR73//KS9DhmppReXq2RKG561azbM5EX2M=; b=mClrTjgCvLnLkYPLyDaJAqLZHjZWLHRyJnFHyylvvGuQNCTbap/oMHxxvqMRU015aP Jdgs9suQsU5c/cOb01WWyj8G+jBCmL/u6IGN5enr/ouNAvw9Q7K6WAL2WMXQNaD749fp 6huHQ0TuJvx97fwd6relb1aQ3VQef/2th7a41wfCG6XRt2kui46VRug+1ffLfBJrusDs kaIymtWFvh6ZcLyLslzZQzknkAj7RRy5N4BbVPuSYVk/WqRLIfaY4I18FqHMcrlpHedE Y4vVZ6lj9BJFOclAAjZc0Ns5S+cZmLK+GrnQu/TY17QxsfygoVo9wYGssa+7Due9CPS8 fzYw== 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=yx8+4pu8liR73//KS9DhmppReXq2RKG561azbM5EX2M=; b=EoST1e9D1LoeG5RnJoSCcARIY0GkdEU+n1VNBfyOJxES3+k/P/b2HJatQpJ/swUXYK UPTt3Dp3jPu5XO4/kpZN0YPU84ClqnH7Bqu21TcNZhoc66etlQPq2SujdQMWtTesdCXJ BVzNsU0eElgMwfViN3MF1UMhOtEGNtO+2FqFtpUP9LEJp7S1ddG/mMbmmg9EwlrKJfuJ j8TnfApBdhsZXaw29Alim3sFqtjKG9VQc8neMvZVTJOrEvJM2NZ0HZ99b34rrQH6L0G2 eSDqILSHJL7POY2XcPtG0zs/hU2Nv477l1XmjKL0Vh40q0CSl1NPehqsdXq+TATVmzyc T6ZQ== X-Gm-Message-State: ALoCoQlJSIGKIYMogelthjqJWCiFuSN5hRX+E4XffmW9MFyefro/Ny6Upurf05qdvsxjccMp5q1q MIME-Version: 1.0 X-Received: by 10.43.151.7 with SMTP id kq7mr5564182icc.78.1402960360414; Mon, 16 Jun 2014 16:12:40 -0700 (PDT) Received: by 10.64.137.40 with HTTP; Mon, 16 Jun 2014 16:12:40 -0700 (PDT) In-Reply-To: References: <20140428231041.12685.8218.idtracker@ietfa.amsl.com> <35B52561-A6B3-43F9-9291-81D46444D3D2@gmail.com> <2FB9B161-A4DB-4905-A9EC-CF05D72EE7A3@gmail.com> Date: Mon, 16 Jun 2014 16:12:40 -0700 Message-ID: From: Chris Palmer To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/ehu-Jn1goL-Z6B7msXwVcpPOJtQ Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt 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: Mon, 16 Jun 2014 23:12:42 -0000 On Mon, May 19, 2014 at 11:28 PM, Trevor Perrin wrote: >> PKP vs. PKP-RO: >> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9 > > The new text about PKP-RO in 2.5 (quoted below) seems to say that a > PKP-RO header is only evaluated against the current connection, not > stored as a pin. I thought we decided the opposite (which is what I > think 2.3.2 is saying): > > 2.3.2 (existing text): > 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 the Pins > and directives given in the Public-Key-Pins-Report-Only header. Most recent text (https://tools.ietf.org/html/draft-ietf-websec-key-pinning-14#section-2.3.2), FWIW: """ If a Host sets both the PKP header and the PKP-RO header, the UA MUST note and enforce Pin Validation as specified by the PKP header, and SHOULD note the Pins and directives given in the PKP-RO header. If the UA does note the Pins and directives in the PKP-RO 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. """ So, the bug is still present. I will change "note" to "process", indicating that the UA need not store anything about the PKP-RO header. Indeed its purpose is ephemeral, and I don't see any reason to store anything, *except for the purpose of determining that it has already sent a report for a given policy*. I'll add some text to that effect. > 2.5 (new text): > The UA SHOULD NOT note any pins or other policy expressed in the PKP- > RO response header field. I'll add the text in this section. Here's the change: https://code.google.com/p/key-pinning-draft/source/detail?r=fed01d71c5012137c2fb483b0ccad21b83b5888b From nobody Mon Jun 16 16:13: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 E95931A02BD for ; Mon, 16 Jun 2014 16:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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.651, 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 CzoCXGnl0J7M for ; Mon, 16 Jun 2014 16:13:17 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28851A02BE for ; Mon, 16 Jun 2014 16:13:16 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id a13so3534371igq.3 for ; Mon, 16 Jun 2014 16:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o0CLP6SNfvi11+b32E9kRGqnteUHXyBBqMuzTBRI9Cs=; b=CexUY9cQu2i7IKX0NINaqRbZ1mPnUyMnOJVOCk1QzfR1PsTtHzhy9TxWI2NOMxEIh5 gw3ykjRQdWDVBvWitijuHz4h2BeY9LMhgWXa0eRzweB+cpT9HVKg98Npc4F6HEzAcPiN vLRqDMneWbRBo42Rc9Im/ylYi1yFFlhIpS1ldC1jdS0ut2yTYgBoTx3qe1febboDKoWv lXvRczUq18UBWUFzHCVhwBXXpAyVUeh0sI9BVI6JV1W6vow2QWEwFoiopSNEmV7vTZXb uH4cBOVSEaL7ReKg02Zh0TJ4l4i7FluM7uYMhnOg30POERUMVCpU0hjKYs/V0//mBvrl aJuQ== 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=o0CLP6SNfvi11+b32E9kRGqnteUHXyBBqMuzTBRI9Cs=; b=airFn5xRZg9WD9bvyeyKZIXVG2pUWZBmvspE95BFn85+4o/RtocqrIWu7wYjjLfjr6 N3ol0nOAr5K3ahWVp6OiMdtqtB/7/+CCK75Vs/t6KrB77Xr1kW14QR0Uy+S+OGGJPLew Emen8hb3QgWFc52a3q2EYoLcwk/eNr/76udOLZu3HRRWYhJoc+w2IcL5HJ87CHqCK5vv vdu//gIQ1e4urqUigXUUTc/b8DHsUUxMxLR++uC7pRBxe1t+bfSiN/6cJDpzuf8yh9hE Z1PJ1BSrdAxSRIBO22aYLusCJWuUqGd4rm+e9Cv+uPXFIHyjz75Cil8Kh0BP2w+/pTgc NwMA== X-Gm-Message-State: ALoCoQlGHixZekCQqRkVhD6bUzynM6wWfjqylgbOp6fsQe8cJH6sCyQXReacQmQWYiYmz08XaQUG MIME-Version: 1.0 X-Received: by 10.50.6.36 with SMTP id x4mr29337926igx.13.1402960396248; Mon, 16 Jun 2014 16:13:16 -0700 (PDT) Received: by 10.64.137.40 with HTTP; Mon, 16 Jun 2014 16:13:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 16:13:16 -0700 Message-ID: From: Chris Palmer To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/02uYiy-VINpRTGz9dIFS0SB_jJc Cc: IETF WebSec WG Subject: Re: [websec] PKP-RO (was Re: I-D Action: draft-ietf-websec-key-pinning-12.txt) 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: Mon, 16 Jun 2014 23:13:19 -0000 Sorry it took me a while. See the other thread; I think it's handled reasonably well now? On Wed, Jun 4, 2014 at 5:48 PM, Trevor Perrin wrote: > Anyone have comments on below? Is there agreement on what PKP-RO should do yet? > > > On Mon, May 19, 2014 at 11:28 PM, Trevor Perrin wrote: >> On Tue, May 13, 2014 at 2:09 PM, Chris Palmer wrote: >>> >>> PKP vs. PKP-RO: >>> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9 >> >> The new text about PKP-RO in 2.5 (quoted below) seems to say that a >> PKP-RO header is only evaluated against the current connection, not >> stored as a pin. I thought we decided the opposite (which is what I >> think 2.3.2 is saying): >> >> 2.3.2 (existing text): >> 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 the Pins >> and directives given in the Public-Key-Pins-Report-Only header. >> >> 2.5 (new text): >> The UA SHOULD NOT note any pins or other policy expressed in the PKP- >> RO response header field. > > > Trevor From nobody Mon Jun 16 16:34:02 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 E1CED1A02C1; Mon, 16 Jun 2014 16:33:59 -0700 (PDT) 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 cFeMMVhKn7xY; Mon, 16 Jun 2014 16:33:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE81A02C9; Mon, 16 Jun 2014 16:33:55 -0700 (PDT) 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.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140616233355.16550.96950.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 16:33:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/_p_38_2HBgAUgzCawMzSeoFXGBk Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-15.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: Mon, 16 Jun 2014 23:34:00 -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-15.txt Pages : 26 Date : 2014-06-16 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-15 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 nobody Wed Jun 18 14:13:26 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 C3C821A0195 for ; Wed, 18 Jun 2014 14:13:12 -0700 (PDT) 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 qKfpqyZt73Th for ; Wed, 18 Jun 2014 14:13:09 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0881A0319 for ; Wed, 18 Jun 2014 14:12:59 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so9135720wib.2 for ; Wed, 18 Jun 2014 14:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=FvBXRR3ZTZrwhtzOMyD27IMzS2V7skZOjpAMPmPDaeA=; b=pJg5GmNhADYMUuqk2vLuZtJgmrl8GLL48zY1PRzj4LbDtDmCQPkFE8xwNcYrf6lncm n0FFDKUhNPbQsF+2/tMCSV72r0BZgzknzceho4fWV5Fav1IyhQ74x9+rpvskWmzWY00w HfobgMaEEzsnfeODQXXTO6GOJSV+8y6Z1PEqSBUi8USyZp6RnY4a3KK8XDYxBmb5URzn QgmcBKu8imjDko2SIyt2VC3w5ld5+2vAZOUpbI+ywF7ZKdXMI9DWhvKevPgJwY0n0kz1 Pw0If4WVtyomp+6DKG9OUDFIUFp1a8XZFbyKzr3HW+MMCvpZZkbwHBofoKOdZTYk7uuD azjA== X-Received: by 10.180.210.134 with SMTP id mu6mr847475wic.18.1403125976184; Wed, 18 Jun 2014 14:12:56 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id e11sm5685464wiw.19.2014.06.18.14.12.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 14:12:55 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_51D117BB-7EFA-4F02-B63A-5DDB23F1D7B3" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Thu, 19 Jun 2014 00:12:52 +0300 References: <20140616233355.16550.96950.idtracker@ietfa.amsl.com> To: IETF WebSec WG In-Reply-To: <20140616233355.16550.96950.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/42-NMBzGa8yEOEN_W0E0FA6FeP0 Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-15.txt 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, 18 Jun 2014 21:13:13 -0000 --Apple-Mail=_51D117BB-7EFA-4F02-B63A-5DDB23F1D7B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks to Ryan and the Chrises for getting this done. Folks, it seem to us that this working group has done as much as we can = for this document. We could keep discussing this for another year, but = we believe at this point this would be counter-productive.=20 So, we intend to send this to Barry next week. Please take the time to = make sure that no huge mistakes have been added in the last two = iterations. For your convenience, here are links to the diffs: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-14 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-15 Thanks again to the authors and people on the list for all the efforts. = I believe we have come up with a document that is implementable and adds = a scalable way to mitigate the threat of mis-issued certificates. As you know, the journey is not quite done, as we still have AD review, = IETF last call, the IESG, and the RFC editor. See you all around. Tobias and Yoav On Jun 17, 2014, at 2:33 AM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Public Key Pinning Extension for HTTP > Authors : Chris Evans > Chris Palmer > Ryan Sleevi > Filename : draft-ietf-websec-key-pinning-15.txt > Pages : 26 > Date : 2014-06-16 >=20 > Abstract: > This memo describes an extension to the HTTP protocol allowing web > host operators to instruct user agents 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-15 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-15 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ --Apple-Mail=_51D117BB-7EFA-4F02-B63A-5DDB23F1D7B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks = to Ryan and the Chrises for getting this done.

Folks, = it seem to us that this working group has done as much as we can for = this document. We could keep discussing this for another year, but we = believe at this point this would be = counter-productive. 

So, we intend to send = this to Barry next week. Please take the time to make sure that no huge = mistakes have been added in the last two iterations. For your = convenience, here are links to the diffs:

Thanks again to the authors and people on = the list for all the efforts. I believe we have come up with a document = that is implementable and adds a scalable way to mitigate the threat of = mis-issued certificates.

As you know, the = journey is not quite done, as we still have AD review, IETF last call, = the IESG, and the RFC editor. See you all = around.

Tobias and = Yoav

On Jun 17, 2014, at 2:33 AM, internet-drafts@ietf.org = wrote:


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
=             &n= bsp;           &nbs= p;Chris Palmer
=             &n= bsp;           &nbs= p;Ryan Sleevi
= Filename        : = draft-ietf-websec-key-pinning-15.txt
Pages =           : = 26
= Date =            : = 2014-06-16

Abstract:
  This memo describes an = extension to the HTTP protocol allowing web
  host = operators to instruct user agents 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:
h= ttps://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-15

= A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-15=


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/

= --Apple-Mail=_51D117BB-7EFA-4F02-B63A-5DDB23F1D7B3-- From nobody Wed Jun 18 14:28:42 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 2C2991A016B for ; Wed, 18 Jun 2014 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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.651, 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 zaqGrSq3dGgH for ; Wed, 18 Jun 2014 14:28:36 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224691A0166 for ; Wed, 18 Jun 2014 14:28:35 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id at1so1268205iec.14 for ; Wed, 18 Jun 2014 14:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ukeew9v+pJ+nKFvS0edFBD6VyNnQ48e0CcHpH4E+BfU=; b=S/CO4jFFg0q9xKI8yLMZcMf2WOXI6SiFtYfmQktd2YxefXkhD58Wt6xqzXSUUSkhV3 AuScOQmzF9Eh95Xs3D0BULkRg78LpEDZJnl1Dv09h5pJw5Lc7+9i79auvTf7ts87bSYn 3Jf5biF0wGGdskePZQjkv8qMkpOEGLf/YQeSdJsCu5KHuEKYD4371/raVGL0YlYDMzmx OXzkxPzB0gF0cEUoXGN6UDUJVqXA3iIyRxqVQ2DSmyT0eL3RkeCmSLybmtY2+Tu7q16R nWBXHYqXPyp5fDgooJvvsF9Qg0YnaysECrD5VCJaFi4usM48Xz1VjQN5wV/2WhZSC7SV iSiw== 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=Ukeew9v+pJ+nKFvS0edFBD6VyNnQ48e0CcHpH4E+BfU=; b=ZJetT9VvhaCXNiAYGSbWTTj8wk7NcMfpdrnrESSCSmzzD4bNtkvbvjmyI79d5NImZU NxBT6NrvDDjE77DOIz/mNiJsMGVUBswOIwv2Wl6oDR/rAcicUlOfwiJ+ZHNwZZMkX5uA hjsCINREuabOlk0b0fhErNvlDm9FkXoOSczupUN8paGUHw62a3yBsTwPuAicP1sgTjOK kySf7RgUfuScWQ5aum8LBfiWsfMA/F2/PAIW0kT4l61FLIRO22Yv489yuMMXmUOh4Tk8 +A2Otsm04cDgWVOxszoF5c4PvNDtNzK/RyKW4RUDiMD7NmXmERbJ7cVzhqvCshmrd7oT PjLQ== X-Gm-Message-State: ALoCoQnukcLEtyS9C7N/RngaxAtukR1s4mgwl2OWuWvlK6nYDzlmrnNncMxcsXHrzGrBjRGYTd3L MIME-Version: 1.0 X-Received: by 10.43.125.199 with SMTP id gt7mr962144icc.70.1403126915387; Wed, 18 Jun 2014 14:28:35 -0700 (PDT) Received: by 10.64.137.40 with HTTP; Wed, 18 Jun 2014 14:28:35 -0700 (PDT) In-Reply-To: References: <20140616233355.16550.96950.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 14:28:35 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/L0yn9zkvzz5_rFcu11PrC6l2L_s Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-15.txt 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, 18 Jun 2014 21:28:38 -0000 And, thanks to everyone for your valuable input. This was (quite obviously :) ) my first adventure in Standards Land, and I know it was rocky. But hopefully we have something now. :) On Wed, Jun 18, 2014 at 2:12 PM, Yoav Nir wrote: > Thanks to Ryan and the Chrises for getting this done. > > Folks, it seem to us that this working group has done as much as we can for > this document. We could keep discussing this for another year, but we > believe at this point this would be counter-productive. > > So, we intend to send this to Barry next week. Please take the time to make > sure that no huge mistakes have been added in the last two iterations. For > your convenience, here are links to the diffs: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-14 > http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-15 > > > Thanks again to the authors and people on the list for all the efforts. I > believe we have come up with a document that is implementable and adds a > scalable way to mitigate the threat of mis-issued certificates. > > As you know, the journey is not quite done, as we still have AD review, IETF > last call, the IESG, and the RFC editor. See you all around. > > Tobias and Yoav > > On Jun 17, 2014, at 2:33 AM, internet-drafts@ietf.org wrote: > > > 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-15.txt > Pages : 26 > Date : 2014-06-16 > > Abstract: > This memo describes an extension to the HTTP protocol allowing web > host operators to instruct user agents 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-15 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-15 > > > 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/ > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From nobody Wed Jun 25 16:02: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 3F5251B283A; Wed, 25 Jun 2014 16:02:18 -0700 (PDT) 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 ldcmpVSZM9EB; Wed, 25 Jun 2014 16:02:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6671B285A; Wed, 25 Jun 2014 16:02:15 -0700 (PDT) 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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140625230215.32215.29604.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 16:02:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/yWK5nTbZqB1ys1_f7ZYJNn3UNHA Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-16.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: Wed, 25 Jun 2014 23:02:18 -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-16.txt Pages : 26 Date : 2014-06-25 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-16 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 nobody Wed Jun 25 16:45: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 5D1DA1B28F5; Wed, 25 Jun 2014 16:45:29 -0700 (PDT) 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 5wWLocEKfgUX; Wed, 25 Jun 2014 16:45:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A911B28FF; Wed, 25 Jun 2014 16:45:26 -0700 (PDT) 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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140625234526.14596.68415.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 16:45:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/aq1jon8gFVhcyiyW9VCi_hTKHIs Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-17.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: Wed, 25 Jun 2014 23:45: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-17.txt Pages : 26 Date : 2014-06-25 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents 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-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-17 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 nobody Thu Jun 26 04:00: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 E2D5F1B2B16 for ; Thu, 26 Jun 2014 04:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 ACMvB478nbuL for ; Thu, 26 Jun 2014 04:00:16 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4155A1B2A61 for ; Thu, 26 Jun 2014 04:00:16 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id 10so2768133lbg.23 for ; Thu, 26 Jun 2014 04:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=In2ZKow753t8AQhwjGuu2HiGZqyCcQdLeA263/S/5zc=; b=KWTOognURv+5be/Z4XKCTZ8G9bx2EYiczbeErdJSqrWr/PrhfOObOp9idAm0Whutyl bWdQGi/6rpZb35D1xrr6Y3JQj75cCgsPMVY7CxT39cb49rI92/GzvxvheInloP0wjGwD gr5qsBDTL5KSxVNg2CQH0oHIh/gYuLBJcq3LQWClgzHmRtO/KDIgTzMQ1CrcqOqePsSw si7MkjKYrNX8wU7uUN25KHTqK6V4DZXt3EFKFTnL2cWW+rCowmRqUa/8CL+P+SqXY6LA AMaV6NId9dlV1NX5jFjQoCtWz8Et+8BirIfwpV/BYyVL5B+YqUF0EyKelAticXxEU5I9 IAsw== MIME-Version: 1.0 X-Received: by 10.152.23.136 with SMTP id m8mr10614334laf.2.1403780414416; Thu, 26 Jun 2014 04:00:14 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Thu, 26 Jun 2014 04:00:14 -0700 (PDT) Date: Thu, 26 Jun 2014 07:00:14 -0400 X-Google-Sender-Auth: YnWfEeQH0LNib9Ca8-VT3Ja0dPI Message-ID: From: Barry Leiba To: draft-ietf-websec-key-pinning.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/H2QlRVuhf9b2DTjDeCj8C9EnSjQ Cc: "websec@ietf.org" Subject: [websec] AD review of draft-ietf-websec-key-pinning-17 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, 26 Jun 2014 11:00:20 -0000 With the publication request for draft-ietf-websec-key-pinning, here's my AD review. I'm putting the document into "Revised I-D Needed" substate. That said, you should definitely push back at me on points below that you disagree with. And note the point about the registry that you're not creating, which I specifically want to discuss with you. Yoav, thanks for a very good shepherd writeup. Tiny thing in the Abstract: we have to squash this "this memo" stuff forever, but it'll probably take forever to do it. Please make it "this document". Similarly in the Introduction: Remember that the text has to make sense after publication. "We propose a new HTTP header to enable..." doesn't do that (even though "Proposed Standard" will be the RFC's status). Go with "This document defines a new HTTP header that enables...". Tiny editorial: I suggest changing "that becomes invalid. (See Section 4.)" to "that becomes invalid (see Section 4)." -- merging the citation into the sentence. There are a couple of other citations in the document that also read like that. And in general, wherever you have a citation that looks like this: ([RFC6234]) ...remove the parentheses so it looks like this: [RFC6234] Is "we believe that" in the middle of the second paragraph something that should stand as it is in the final RFC? And I suggest: OLD We intend for hosts to use PKP together with HSTS ([RFC6797]), but is possible to pin keys without requiring HSTS. NEW PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS. END You could make sure that "This draft is being discussed on the WebSec Working Group mailing list, websec@ietf.org." is removed in AUTH48, and the RFC Editor is likely to catch that anyway, but it can also be removed now: the draft name already points readers to the working group. -- Section 2.1 -- The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header fields, also referred to within this specification as the PKP and PKP-RO header fields, respectively, are are response headers used by server to indicate that a a UA should perform Pin Validation (Section 2.6) in regards to the host emitting the response message containing these header fields, and provide the necessary information for the UA to do so. Apart from the length of that one sentence, there are some typos there. How about this?: NEW The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header fields, also referred to within this specification as the PKP and PKP-RO header fields, respectively, are new response headers defined in this specification. They are used by a server to indicate that a UA should perform Pin Validation (Section 2.6) for the host emitting the response message, and to provide the necessary information for the UA to do so. END 2. All simple-directives MUST appear only once in a given header field. Directives are either optional or required, as stipulated in their definitions. I don't think that's correct. It's certainly not required that each header field contain every simple-directive. I think you mean this: NEW 2. A given simple-directive MUST NOT appear more than once in a given header field. Directives are either optional or required, as stipulated in their definitions. END For list item 4, would it help to explain why? Perhaps, "In particular, UAs must not attempt to fix malformed header fields." ? Additional directives extending the semantic functionality of the header fields can be defined in other specifications, with a registry (having an IANA policy definition of IETF Review [RFC5226]) defined for them at such time. Such future directives will be ignored by UAs implementing only this specification, as well as by generally non- conforming UAs. I don't think it's clear enough that this document doesn't define that registry, and that this is giving instruction for future registry creation. Please talk with me about why you feel the need *now* to say that a future registry will have to use IETF Review as its policy. Why would Specification Required or Expert Review not be OK? Why shouldn't the decision be left for the time the registry is created? In the pin-directive, the token is the name of a cryptographic hash algorithm, and MUST be "sha256". (In the future, additional hash algorithms MAY be registered and used.) The quoted-string is a sequence of base 64 digits: the base 64-encoded SPKI Fingerprint ([RFC4648]). See Section 2.4. I don't like the MUST there (nor the MAY). As to "registered and used", is this intended to be in the same registry as above? So the directive "pin-sha256" would be registered, along with a new "pin-shaXYZ"? Assuming that's right, I'm really starting to think that the registry should be created now. The reason to defer creation is if we think that no new directives will ever really come along, so we won't need the registry. But if the hash algorithm names will be in the registry, we can be pretty sure we'll need new ones. Anyway, a fix for this paragraph (but this will change if we create the registry now) could be like this: NEW In the pin-directive, the token is the name of a cryptographic hash algorithm. The only algorithm allowed at this time is "sha256"; additional algorithms may be defined in the future. The quoted-string is a sequence of base 64 digits: the base 64-encoded SPKI Fingerprint [RFC4648]. See Section 2.4. END The UA MUST ignore pin-directives with tokens naming hash algorithms it does not recognize. If the set of remaining effective pin- directives is empty, and if the connection passed Pin Validation with the UA's existing noted pins for the Host (i.e. the Host is a Known Pinned Host), the UA MUST cease to consider the Host as a Known Pinned Host. (I.e. the UA should fail open.) The UA SHOULD indicate to users that the Host is no longer a Known Pinned Host. The first sentence follows from (5) in the above list, so I suggest you say so. This also appears to be where you define "Known Pinned Host", but you've buried the lede here. I suggest this: NEW When a connection passes Pin Validation using the UA's noted pins for the Host at the time, the Host becomes a Known Pinned Host. According to rule 5, above, the UA MUST ignore pin-directives with tokens naming hash algorithms it does not recognize. If the set of remaining effective pin-directives is empty, and if the Host is a Known Pinned Host, the UA MUST cease to consider the Host as a Known Pinned Host (the UA should fail open). The UA SHOULD indicate to users that the Host is no longer a Known Pinned Host. END On the last sentence, though, I'm really unsure: are we really giving UI advice in a protocol document? Is that a good idea? Do w have any sense that my mother will have the first idea what you're talking about when you indicate this to her? This also is a good place for me to point out that you use "host" and "Host" inconsistently. I think you use "pin" and "Pin" inconsistently as well. The RFC Editor will ask you to fix that, so you can save time by doing it now. Please go through the document and make sure your capitalization in general is purposeful and consistent. -- Section 2.1.1 -- In the first sentence, remove both commas. The second sentence is unnecessary, as it's repeated at the end of the section. -- Section 2.1.2 -- Change "which" to "that" (or the RFC Editor will). -- Section 2.1.3 -- What does it mean to use POST on a URI that isn't http or https? What do you do with a wss URI, for example? Note that the report-uri need not necessarily be in the same Internet domain or web origin as the Known Pinned Host. This is confusing, particularly in context with the previous paragraph. I think you mean this: NEW Note that the host in the report-uri need not necessarily be in the same Internet domain or web origin as the host being reported about. END -- Section 2.2.1 -- Establishing a given host as a Known Pinned Host, in the context of a given UA, MAY be accomplished over the HTTP protocol, which is in turn running over secure transport, by correctly returning (per this specification) at least one valid PKP header field to the UA. Other mechanisms, such as a client-side pre-loaded Known Pinned Host list MAY also be used. There are two problems with this paragraph: 1. It has two sentences, and each sentence gives a MAY directive. That means they're both optional, which means that it's possible to do neither. Really? It seems to me that you mean to say that you do one or the other. 2. The "which is in turn" part is non-restrictive -- it could be removed without changing the meaning. I don't think so. I think you mean to say that it may be accomplished by using HTTP over secure transport -- the secure transport is a necessary part, yes? Assuming so, try this: NEW Establishing a given host as a Known Pinned Host, in the context of a given UA, is accomplished as follows: 1. Over the HTTP protocol running over secure transport, by correctly returning (per this specification) at least one valid PKP header field to the UA. 2. Through other mechanisms, such as a client-side pre-loaded Known Pinned Host list. END -- Section 2.3.1 -- "the UA MUST either" introduces a list of eight items. Only the first two are meant to be part of the "MUST either". I suggest that you pull the last six items out of the list, and just make them regular paragraphs. In the second list item, "different than that already maintained": "different than" is incorrect. Use either "different from" (US) or "different to" (UK). I think the third and fourth items can be in one paragraph. "Otherwise:" is not necessary. The sixth and seventh items can be merged into one paragraph (one sentence). -- Section 2.3.2 -- This section should say what to do with the KPH cached information if a PKP-RO header is received. If the Pin Validation fails, it's clear what to do. But if Pin Validation succeeds, does the host become a KPH? If it's already a KPH, is the cached information updated? If there's both a PKP header and a PKP-RO header, Pin Validation succeeds for both, and they have different directives, which wins with respect to the KPH cached information? -- Section 2.3.3 -- The UA MUST ignore all expired Known Pinned Hosts from its cache if, at any time, an expired Known Pinned Host exists in the cache. Eh? I don't understand what this is trying to say. Do you mean "MUST *remove* them from its cache? What's with the "at any time" bit? Please try rephrasing this -- I don't understand it well enough to try. For the second paragraph, I would add something more explanatory to real humans here, inserted as a first sentence: "Known Pinned Hosts are only domain names, and never IP addresses." And here we have another hugely long sentence. Please keep in mind that when sentences get too long, people have trouble understanding them. OLD Otherwise, if the substring does not congruently match a Known Pinned Host's domain name, per the matching procedure specified in Section 8.2 of [RFC6797], then the UA MUST note this host as a Known Pinned Host, caching the Pinned Host's domain name and noting along with it the Effective Expiration Date (or enough information to calculate it, i.e. the Effective Pin Date and the value of the max- age directive), whether or not the includeSubDomains directive is asserted, the value of the report-uri directive (if present). If any other metadata from optional or future PKP header directives is present in the Valid Pinning Header, the UA MAY note them if it understands them, and need not note them if it does not understand them. NEW Otherwise, if the substring does not congruently match an existing Known Pinned Host's domain name, per the matching procedure specified in Section 8.2 of [RFC6797], then the UA MUST add this host to the Known Pinned Host cache. The UA caches: o the Pinned Host's domain name, o the Effective Expiration Date, or enough information to calculate (the Effective Pin Date and the value of the max-age directive), o whether or not the includeSubDomains directive is asserted, and o the value of the report-uri directive, if present. If any other metadata from optional or future PKP header directives are present in the Valid Pinning Header, and the UA understands them, the UA MAY note them as well. END -- Section 2.4 -- (Future versions of this specification may add new algorithms and deprecate old ones.) I would say "Future specifications"; algorithms might be added or deprecated in extensions, not necessarily in future versions of *this* specification. If the certificate's subjectPublicKeyInfo is incomplete when taken in isolation, such as when holding a DSA key without domain parameters, a public key pin cannot be formed. Hence, pins using these keys cannot be pinned. The second sentence is silly. *Pins* aren't pinned. Either remove the sentence (it's redundant anyway) or change the subject. -- Section 2.5 -- Upon receipt of the PKP response header field, the UA notes the host as a Pinned Host, storing the Pins and their associated directives in non-volatile storage "as a Known Pinned Host"... need to use terminology consistently. The three-bullet list is wrong: the first phrase of each must be factored out, because the "if and only if" applies to all three points together. So, like this: OLD The UA MUST observe these conditions when noting a Host: o The UA MUST note the Pins if and only if it received the PKP response [...] o The UA MUST note the Pins if and only if the TLS connection [...] o The UA MUST note the Pins if and only if the given set of Pins contains [...] NEW The UA MUST note the Pins for a Host if and only if all three of the following conditions hold: o It received the PKP response [...] o The TLS connection [...] o The given set of Pins contains [...] END -- Section 2.6 -- A UA SHOULD perform Pin Validation whenever connecting to a Known Pinned Host, but MAY allow Pin Validation to be disabled for Hosts according to local policy. Typical SHOULD/MAY trap. MAY is not an explanation of when you can violate SHOULD. MAY means that something is entirely optional. NEW A UA SHOULD perform Pin Validation whenever connecting to a Known Pinned Host. It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. END Although the UA has previously received Pins at the HTTP layer, it can and MUST perform Pin Validation at the TLS layer, before beginning an HTTP conversation over the TLS channel. The TLS layer thus evaluates TLS connections with pinning information the UA received previously, regardless of mechanism: statically preloaded, via HTTP header, or some other means (possibly in the TLS layer itself). Can you re-word this? It seems very strained, and I don't understand it. There's no background for telling me what the UA has previously received. I thought Pins *only* happened with TLS, so how can they have been received without it? And please avoid phrasing such as "can and MUST"; it if MUST, it clearly can, or else the MUST is meaningless. For the last paragraph of the section, the combined negatives can be confusing, but the structure is necessary in order for the SHOULD NOT to work. Perhaps an inserted first sentence that explains it affirmatively will help: "UAs send validation failure reports only when Pin Validation is actually in effect." -- Section 2.7 -- In the first sentence, again, you're giving UI advice, and advice that I find questionable. This is an option that will *only* be applicable to expert users, and that won't be understood, much less used, by 99.999% of UA users (certainly not by my mother). I can't imagine how such advice, well intentioned though it may be, merits a SHOULD. -- Section 3 -- include-subdomains indicates whether or not the UA has noted the includeSubDomains directive for the Known Pinned Host. It is provided as one of the JSON identifiers true or false. I would put "true" and "false" in quotes in the text. -- Section 4.3 -- Because having a backup key pair is so important to recovery, UAs MUST require that hosts set a Backup Pin. (See Section 2.5.) Unless I misunderstand, this requirement means that if my server doesn't send a backup pin, my server doesn't benefit from key pinning (it's as though I never included the header in the first place). If that's not true, then Section 2.5 needs to be fixed to make it clear that failure to include a backup pin constitutes a validation failure. If that is true, then you're trading off recovery for security, and I expect the Security ADs to question that. To head that off, it might be good to acknowledge that here, and perhaps to say a few more words about it. -- Section 7 -- I'll repeat the comment here about giving UI advice, especially with SHOULDs and MUSTs. The portion of users who will have any idea what you're talking about is vanishingly small. -- Appendix B -- I *strongly* advise you to pull the SHOULDs out of here, and talk about this advice without using 2119 key words. None of this has anything to do with interoperability of the protocol -- it's all quality of implementation/deployment stuff. -- Barry, Applications AD From nobody Thu Jun 26 09:03: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 832DB1B2C27 for ; Thu, 26 Jun 2014 09:03:07 -0700 (PDT) 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 uyeNQW6e1heH for ; Thu, 26 Jun 2014 09:03:04 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9C51B2D5F for ; Thu, 26 Jun 2014 08:07:01 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so3846837wes.10 for ; Thu, 26 Jun 2014 08:06:58 -0700 (PDT) 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=9hnU942+GhBa8BwM6ohbvRoEYnemzfCFxv79Bhaaagk=; b=S4mMQCATyU9Y+4H3ButB/jCGaQ9cDVI2GAuB3/M6YOclFollRuu3wPJZZemTuuQT/K KLAEbZxrVAT+s9iQHvp0c1GcpC+PeHChBPrCKsgeEduY1gBml6nfvokWjpxCG1egseTB uOl6JWk/gssbcfUR1vlHvEt+v9S/15BqN9wo08gw+xC0t8c2owu5X+wPZGw1DYzFUM+i WUge99JHWBbqUcdKY9eKKVzD7594Mg9dZqM1LlOGUi2Fbqi//pdusLkjVjg9+Zxezjn+ TsmVXZlajrG4sMA2xgKngQotLIgTfQgBRA2CmKzuiJQFsX2oI3x+/nNTlx5xeOTt9FXN /yEg== X-Received: by 10.194.71.132 with SMTP id v4mr18793006wju.102.1403795217173; Thu, 26 Jun 2014 08:06:57 -0700 (PDT) Received: from [172.24.251.205] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id cz4sm66789706wib.23.2014.06.26.08.06.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 08:06:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3D88E97-94B2-4F7D-822F-8FEFCF27287F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Thu, 26 Jun 2014 18:06:48 +0300 Message-Id: References: To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/plrwLPUS7I0BujsyG76Ks7prF1c Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, "websec@ietf.org" Subject: Re: [websec] AD review of draft-ietf-websec-key-pinning-17 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, 26 Jun 2014 16:03:07 -0000 --Apple-Mail=_E3D88E97-94B2-4F7D-822F-8FEFCF27287F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, Barry. Authors: you seem to have your work cut out for you. And to the rest = of the working group: there is a good reason why Barry has sent this to = the list. Dealing with the AD review is a task for the working group, = not only the authors and chairs. So everyone, please feel free to jump = in. The below responses are my own and have no hats. I=92m skipping the = language ones, because me not American, me no talk English good.=20 On Jun 26, 2014, at 2:00 PM, Barry Leiba = wrote: > Is "we believe that" in the middle of the second paragraph something > that should stand as it is in the final RFC? We believe that, with care, host operators can greatly reduce the risk of main-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. I think this should stay.=20 >=20 > Additional directives extending the semantic functionality of the > header fields can be defined in other specifications, with a = registry > (having an IANA policy definition of IETF Review [RFC5226]) defined > for them at such time. Such future directives will be ignored by = UAs > implementing only this specification, as well as by generally non- > conforming UAs. >=20 > I don't think it's clear enough that this document doesn't define that > registry, and that this is giving instruction for future registry > creation. Please talk with me about why you feel the need *now* to > say that a future registry will have to use IETF Review as its policy. > Why would Specification Required or Expert Review not be OK? Why > shouldn't the decision be left for the time the registry is created? I agree with that. How about: NEW: Additional directives extending the semantic functionality of the header fields can be defined in other specifications. The first=20 such specification will need to define a registry for such=20 directives. > In the pin-directive, the token is the name of a cryptographic hash > algorithm, and MUST be "sha256". (In the future, additional hash > algorithms MAY be registered and used.) The quoted-string is a > sequence of base 64 digits: the base 64-encoded SPKI Fingerprint > ([RFC4648]). See Section 2.4. >=20 > I don't like the MUST there (nor the MAY). As to "registered and > used", is this intended to be in the same registry as above? So the > directive "pin-sha256" would be registered, along with a new > "pin-shaXYZ"? >=20 > Assuming that's right, I'm really starting to think that the registry > should be created now. The reason to defer creation is if we think > that no new directives will ever really come along, so we won't need > the registry. But if the hash algorithm names will be in the > registry, we can be pretty sure we'll need new ones. This I will push back on. The day SHA-256 becomes not good enough for = this purpose is when there is a second pre-image attack against SHA-256. = We don=92t have that yet even for MD5. I don=92t think we=92re going to = *need* a pin-SHA512 or a pin-SHA3-256. Somebody might *want* a = pin-GOST-R34.11-94, but in that case I=92m happy to leave the work of = setting up a registry to them. > Anyway, a fix for this paragraph (but this will change if we create > the registry now) could be like this: >=20 > NEW > In the pin-directive, the token is the name of a cryptographic hash > algorithm. The only algorithm allowed at this time is "sha256"; > additional algorithms may be defined in the future. The = quoted-string > is a sequence of base 64 digits: the base 64-encoded SPKI = Fingerprint > [RFC4648]. See Section 2.4. > END I=92m fine with this change. > The UA MUST ignore pin-directives with tokens naming hash algorithms > it does not recognize. If the set of remaining effective pin- > directives is empty, and if the connection passed Pin Validation = with > the UA's existing noted pins for the Host (i.e. the Host is a Known > Pinned Host), the UA MUST cease to consider the Host as a Known > Pinned Host. (I.e. the UA should fail open.) The UA SHOULD = indicate > to users that the Host is no longer a Known Pinned Host. >=20 > The first sentence follows from (5) in the above list, so I suggest > you say so. This also appears to be where you define "Known Pinned > Host", but you've buried the lede here. I suggest this: >=20 > NEW > When a connection passes Pin Validation using the UA's noted pins > for the Host at the time, the Host becomes a Known Pinned Host. >=20 > According to rule 5, above, the UA MUST ignore pin-directives with > tokens naming hash algorithms it does not recognize. If the set of > remaining effective pin-directives is empty, and if the Host is a > Known Pinned Host, the UA MUST cease to consider the Host as a Known > Pinned Host (the UA should fail open). The UA SHOULD indicate to > users that the Host is no longer a Known Pinned Host. > END >=20 > On the last sentence, though, I'm really unsure: are we really giving > UI advice in a protocol document? Is that a good idea? Do w have any > sense that my mother will have the first idea what you're talking > about when you indicate this to her? We do often write sentences like =93This event should be logged.=94 I = don=92t think either your mother or mine regularly run Console.app or = eventvwr.exe to check logs. I guess this is the equivalent statement for = user agents. It makes sense that if there is some indication that a = website is pinned, that indication SHOULD be gone when the website is = unpinned. It=92s not for us to say how a particular vendor will indicate = pinning in their UI, but I think it=92s reasonable to say that the = pinning indication should be gone. > -- Section 4.3 -- >=20 > Because having a backup key pair is so important to recovery, UAs > MUST require that hosts set a Backup Pin. (See Section 2.5.) >=20 > Unless I misunderstand, this requirement means that if my server > doesn't send a backup pin, my server doesn't benefit from key pinning > (it's as though I never included the header in the first place). If > that's not true, then Section 2.5 needs to be fixed to make it clear > that failure to include a backup pin constitutes a validation failure. >=20 > If that is true, then you're trading off recovery for security, and I > expect the Security ADs to question that. To head that off, it might > be good to acknowledge that here, and perhaps to say a few more words > about it. How about: The down side of keeping a not-yet-deployed key pair is that if an attacker gains control of the private key she will be able to perform a MitM attack without being discovered. Care must be taken to avoid leaking the key, such as keeping it offline. Yoav= --Apple-Mail=_E3D88E97-94B2-4F7D-822F-8FEFCF27287F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks, Barry.

Authors: you seem = to have your work cut out for you.   And to the rest of the working = group: there is a good reason why Barry has sent this to the list. = Dealing with the AD review is a task for the working group, not only the = authors and chairs. So everyone, please feel free to jump = in.

The below responses are my own and have no = hats.  I=92m skipping the language ones, because me not American, = me no talk English good. 

On Jun 26, 2014, = at 2:00 PM, Barry Leiba <barryleiba@computer.org> = wrote:

Is "we believe that" in the = middle of the second paragraph something
that should stand as it is = in the final RFC?

                We believe that, with care, =
host operators can greatly
   reduce the risk of main-in-the-middle (MITM) attacks and other false-
   authentication problems for their users without incurring undue =
risk.

I think this should = stay. 


=   Additional directives extending the semantic functionality = of the
  header fields can be defined in other = specifications, with a registry
  (having an IANA policy = definition of IETF Review [RFC5226]) defined
  for them at = such time.  Such future directives will be ignored by UAs
=   implementing only this specification, as well as by = generally non-
  conforming UAs.

I don't think it's = clear enough that this document doesn't define that
registry, and = that this is giving instruction for future registry
creation. =  Please talk with me about why you feel the need *now* to
say = that a future registry will have to use IETF Review as its = policy.
Why would Specification Required or Expert Review not be OK? =  Why
shouldn't the decision be left for the time the registry is = created?

I agree with that. How = about:

NEW:
 =  Additional directives extending the semantic functionality of = the
   header fields can = be defined in other specifications. The = first 
   such = specification will need to define a registry for = such 
  =  directives.

=   In the pin-directive, the token is the name of a = cryptographic hash
  algorithm, and MUST be "sha256". =  (In the future, additional hash
  algorithms MAY be = registered and used.)  The quoted-string is a
=   sequence of base 64 digits: the base 64-encoded SPKI = Fingerprint
  ([RFC4648]).  See Section 2.4.

I = don't like the MUST there (nor the MAY).  As to "registered = and
used", is this intended to be in the same registry as above? =  So the
directive "pin-sha256" would be registered, along with a = new
"pin-shaXYZ"?

Assuming that's right, I'm really starting = to think that the registry
should be created now.  The reason to = defer creation is if we think
that no new directives will ever really = come along, so we won't need
the registry.  But if the hash = algorithm names will be in the
registry, we can be pretty sure we'll = need new ones.

This I will push back on. = The day SHA-256 becomes not good enough for this purpose is when there = is a second pre-image attack against SHA-256. We don=92t have that yet = even for MD5. I don=92t think we=92re going to *need* a pin-SHA512 or a = pin-SHA3-256.  Somebody might *want* a pin-GOST-R34.11-94, but in = that case I=92m happy to leave the work of setting up a registry to = them.

Anyway, a fix for this = paragraph (but this will change if we create
the registry now) could = be like this:

NEW
  In the pin-directive, the token = is the name of a cryptographic hash
  algorithm.  The = only algorithm allowed at this time is "sha256";
=   additional algorithms may be defined in the future. The = quoted-string
  is a sequence of base 64 digits: the base = 64-encoded SPKI Fingerprint
  [RFC4648].  See Section = 2.4.
END

I=92m fine with this = change.

  The UA MUST = ignore pin-directives with tokens naming hash algorithms
=   it does not recognize.  If the set of remaining = effective pin-
  directives is empty, and if the = connection passed Pin Validation with
  the UA's existing = noted pins for the Host (i.e. the Host is a Known
  Pinned = Host), the UA MUST cease to consider the Host as a Known
=   Pinned Host.  (I.e. the UA should fail open.)  The = UA SHOULD indicate
  to users that the Host is no longer a = Known Pinned Host.

The first sentence follows from (5) in the = above list, so I suggest
you say so.  This also appears to be = where you define "Known Pinned
Host", but you've buried the lede = here.  I suggest this:

NEW
  When a connection = passes Pin Validation using the UA's noted pins
  for the = Host at the time, the Host becomes a Known Pinned Host.

=   According to rule 5, above, the UA MUST ignore = pin-directives with
  tokens naming hash algorithms it = does not recognize.  If the set of
  remaining = effective pin-directives is empty, and if the Host is a
=   Known Pinned Host, the UA MUST cease to consider the Host as = a Known
  Pinned Host (the UA should fail open).  The = UA SHOULD indicate to
  users that the Host is no longer a = Known Pinned Host.
END

On the last sentence, though, I'm = really unsure: are we really giving
UI advice in a protocol document? =  Is that a good idea?  Do w have any
sense that my mother = will have the first idea what you're talking
about when you indicate = this to her?

We do often write = sentences like =93This event should be logged.=94 I don=92t think either = your mother or mine regularly run Console.app or eventvwr.exe to check = logs. I guess this is the equivalent statement for user agents. It makes = sense that if there is some indication that a website is pinned, that = indication SHOULD be gone when the website is unpinned. It=92s not for = us to say how a particular vendor will indicate pinning in their UI, but = I think it=92s reasonable to say that the pinning indication should be = gone.

-- Section 4.3 = --

  Because having a backup key pair is so important = to recovery, UAs
  MUST require that hosts set a Backup = Pin. (See Section 2.5.)

Unless I misunderstand, this requirement = means that if my server
doesn't send a backup pin, my server doesn't = benefit from key pinning
(it's as though I never included the header = in the first place).  If
that's not true, then Section 2.5 needs = to be fixed to make it clear
that failure to include a backup pin = constitutes a validation failure.

If that is true, then you're = trading off recovery for security, and I
expect the Security ADs to = question that.  To head that off, it might
be good to = acknowledge that here, and perhaps to say a few more words
about = it.

How about:
The down side of keeping a not-yet-deployed key = pair
is that if an attacker gains control of the = private
key she = will be able to perform a MitM attack without = being
discovered. = Care must be taken to avoid leaking the key, such
as keeping it = offline.


Yoav
= --Apple-Mail=_E3D88E97-94B2-4F7D-822F-8FEFCF27287F-- From nobody Mon Jun 30 11:12: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 36C7F1A03D0 for ; Mon, 30 Jun 2014 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 an33e9CbyTTu for ; Mon, 30 Jun 2014 11:12:09 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2611A03E5 for ; Mon, 30 Jun 2014 11:12:08 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so8509181veb.2 for ; Mon, 30 Jun 2014 11:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Z69P3kzCP5jCpkf7qCkO/SGuEE3cmTnu7eAr6bjO/Ns=; b=HmKO/CYPqcJUhPbESdAXbvw4HGFJwcFTEsFYrsVw2gNwLPQe8uA4fJNBuZ9y+PSxM/ M9gqEcVJ60guSgIHtrHu/zIVeLAbjxcvwd/VguOEREwUIlcFodNB/ExnAwNiXLZDon2E iRyKGlO+wzHDNd3hf3q8+avUJfOepurf3g9GQjfgFe0r5oDH/Gfg0+MvNbV09AkyI5dm YlKL3l032UUINl3UiRxeA4yItpzRHc92knRSaNqVnG9v9Q8J8RYvcbwLJOV3atHpTrtN 9YjNsaIFhSasNsSnCuoKuyZoqfHz7Tr3WUGahbCm9slZS7CjcYTS/GlxQgUwCPv/VyjS QiaQ== MIME-Version: 1.0 X-Received: by 10.220.203.134 with SMTP id fi6mr29811504vcb.18.1404151927915; Mon, 30 Jun 2014 11:12:07 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Mon, 30 Jun 2014 11:12:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jun 2014 14:12:07 -0400 X-Google-Sender-Auth: xTBDBoWkboEMwsmu5PQxSHCuH4Y Message-ID: From: Barry Leiba To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/NYLQB1vsyy94m_p2Hg_Rrf7Ssl4 Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, "websec@ietf.org" Subject: Re: [websec] AD review of draft-ietf-websec-key-pinning-17 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: Mon, 30 Jun 2014 18:12:10 -0000 Yoav, thanks for the comments. I hope the authors will also comment tout de suite, so we can move this document along. > Authors: you seem to have your work cut out for you. And to the rest of > the working group: there is a good reason why Barry has sent this to the > list. Dealing with the AD review is a task for the working group, not onl= y > the authors and chairs. So everyone, please feel free to jump in. Indeed: please do jump in. > The below responses are my own and have no hats. I=E2=80=99m skipping th= e language > ones, because me not American, me no talk English good. .=D7=92=D7=9D =D7=9C=D7=99 =D7=91=D7=A2=D7=91=D7=A8=D7=99=D7=AA >> Is "we believe that" in the middle of the second paragraph something >> that should stand as it is in the final RFC? > > We believe that, with care, host operators can greatly > reduce the risk of main-in-the-middle (MITM) attacks and other false- > authentication problems for their users without incurring undue risk. > > I think this should stay. OK, I'll let that drop, then. I do wish we could find a better way to say it than "we believe", but if no other ADs bring that up I'll say no more about it. >> I don't think it's clear enough that this document doesn't define that >> registry, and that this is giving instruction for future registry >> creation. Please talk with me about why you feel the need *now* to >> say that a future registry will have to use IETF Review as its policy. >> Why would Specification Required or Expert Review not be OK? Why >> shouldn't the decision be left for the time the registry is created? > > I agree with that. How about: > > NEW: > Additional directives extending the semantic functionality of the > header fields can be defined in other specifications. The first > such specification will need to define a registry for such > directives. That sounds fine. >> In the pin-directive, the token is the name of a cryptographic hash >> algorithm, and MUST be "sha256". (In the future, additional hash >> algorithms MAY be registered and used.) The quoted-string is a >> sequence of base 64 digits: the base 64-encoded SPKI Fingerprint >> ([RFC4648]). See Section 2.4. >> >> I don't like the MUST there (nor the MAY). As to "registered and >> used", is this intended to be in the same registry as above? So the >> directive "pin-sha256" would be registered, along with a new >> "pin-shaXYZ"? >> >> Assuming that's right, I'm really starting to think that the registry >> should be created now. The reason to defer creation is if we think >> that no new directives will ever really come along, so we won't need >> the registry. But if the hash algorithm names will be in the >> registry, we can be pretty sure we'll need new ones. > > This I will push back on. The day SHA-256 becomes not good enough for thi= s > purpose is when there is a second pre-image attack against SHA-256. We do= n=E2=80=99t > have that yet even for MD5. I don=E2=80=99t think we=E2=80=99re going to = *need* a pin-SHA512 > or a pin-SHA3-256. Somebody might *want* a pin-GOST-R34.11-94, but in th= at > case I=E2=80=99m happy to leave the work of setting up a registry to them= . Again, I'll let this go... but I'm not terribly happy about it. It's not a question of whether or when we'll get *rid* of 256, but whether and when we'll add a new one as an alternative. As soon as we do, whether it be SHA-512, some SHA3 variant, or some GOST thing, it'll be up to someone else to create the registry. That someone might not be in as good a position to do it as we are now. But if you're really confident that we're likely never to actually need the registry, I'll drop this one as well. >> NEW >> When a connection passes Pin Validation using the UA's noted pins >> for the Host at the time, the Host becomes a Known Pinned Host. >> >> According to rule 5, above, the UA MUST ignore pin-directives with >> tokens naming hash algorithms it does not recognize. If the set of >> remaining effective pin-directives is empty, and if the Host is a >> Known Pinned Host, the UA MUST cease to consider the Host as a Known >> Pinned Host (the UA should fail open). The UA SHOULD indicate to >> users that the Host is no longer a Known Pinned Host. >> END >> >> On the last sentence, though, I'm really unsure: are we really giving >> UI advice in a protocol document? Is that a good idea? Do w have any >> sense that my mother will have the first idea what you're talking >> about when you indicate this to her? > > We do often write sentences like =E2=80=9CThis event should be logged.=E2= =80=9D I don=E2=80=99t > think either your mother or mine regularly run Console.app or eventvwr.ex= e > to check logs. I guess this is the equivalent statement for user agents. = It > makes sense that if there is some indication that a website is pinned, th= at > indication SHOULD be gone when the website is unpinned. It=E2=80=99s not = for us to > say how a particular vendor will indicate pinning in their UI, but I thin= k > it=E2=80=99s reasonable to say that the pinning indication should be gone= . As straight advice, I think "You ought to log this," is vastly different to "You ought to tell this to the end user." The former is something we know a lot about: what information is critical for problem determination. We know little to nothing about what's helpful or not in user interfaces. (I also don't think our advice on logging should be using 2119 language, as it's not a protocol interoperability issue.) You say that these indicators make sense; I contend that they don't. First, users have no idea what pinning means. Second, from the user's point of view, if you've confirmed the identity of the server, the user doesn't care whether you did that with key pinning or not, whether you did it with DANE or not, whether you did it by checking the CAs or not, or whatever. My sense (as a non-UI-designer) is that if you're going to tell the user anything, it's purely that the site's identity has been confirmed (or not). Nothing about the mechanism matters. I don't see why there's any value in indicating pinning in a UI. >> -- Section 4.3 -- >> >> Because having a backup key pair is so important to recovery, UAs >> MUST require that hosts set a Backup Pin. (See Section 2.5.) >> >> Unless I misunderstand, this requirement means that if my server >> doesn't send a backup pin, my server doesn't benefit from key pinning >> (it's as though I never included the header in the first place). If >> that's not true, then Section 2.5 needs to be fixed to make it clear >> that failure to include a backup pin constitutes a validation failure. >> >> If that is true, then you're trading off recovery for security, and I >> expect the Security ADs to question that. To head that off, it might >> be good to acknowledge that here, and perhaps to say a few more words >> about it. > > How about: > The down side of keeping a not-yet-deployed key pair > is that if an attacker gains control of the private > key she will be able to perform a MitM attack without being > discovered. Care must be taken to avoid leaking the key, such > as keeping it offline. That's fine to add, but it doesn't get to the point of my question. The point wasn't about securing the backup key. The point is this: Suppose I give you a pin, but not a backup pin. There are two things you can do: 1. Accept the pin, and proceed along happily unless and until I do something that makes that pin invalid. At that point, lacking a backup, you start denying access to my server. 2. Do not accept the pin because there's no backup, and proceed as though I hadn't sent the pin. The spec has chosen path 2. I'm questioning whether that's really the right path. It seems to me that (2) is less secure (because I don't get pinning), and you're choosing it just in case (1) might happen. Why wouldn't the better approach be to say that you SHOULD send a backup pin, and warn what can happen if you don't. And then if a server doesn't, and becomes inaccessible for a time as a result, it's their own fault for not paying attention to the advice? Barry