Re: [websec] draft-ietf-websec-key-pinning
Tom Ritter <tom@ritter.vg> Tue, 26 August 2014 23:08 UTC
Return-Path: <tom@ritter.vg>
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 E4C661A00A6 for <websec@ietfa.amsl.com>; Tue, 26 Aug 2014 16:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2nqYm7w0fxg for <websec@ietfa.amsl.com>; Tue, 26 Aug 2014 16:08:17 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B901A008F for <websec@ietf.org>; Tue, 26 Aug 2014 16:08:17 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id y20so12624079ier.13 for <websec@ietf.org>; Tue, 26 Aug 2014 16:08:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dbDKeBn52D5fCIRGeQgXGR6EOoigkaSFatLig3OSxRU=; b=oZOWG1e0DnBinm1m3pGkoLU29r14qEO9fEVLUJJP0s82i/7takuyPGICYLxDFk5/5Q qagL5Ok7lCaF+m838O9aoIOoSwSZ+Wh5P9PBGq4ZZvle2x4eQBia0shhHKKCI9HfFYIp +8gM3FAhBk8Xla/WxmKKUG9K/fYNcRJGW29/g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dbDKeBn52D5fCIRGeQgXGR6EOoigkaSFatLig3OSxRU=; b=k75OrtDsO2UD6fvgF+U9T88j3l4O0+ADQHfHpB5rkihFXMrHMCTyRzLiBu1epik/Cj 5VOdEdZWB/U7wJsRqZSvZSr/v9BTdf0Xi0NXLfTZaUJzwdqCiPQ2AAgQtuNJBgYeAF17 q1GN+vYzqGi3RQxKCNGTxB64R2bnZDnHXIzcg8A9cX5XUDzz9o2nqHWbZ1Bbyj+1pPoY gaIe+G7cGt/nZbP4TYNBxVRLHATwiwLrF0sdNvOFuRG11h6JUEQG/hzNlbILA/oHpIYF Wgop1qJyudMz1IdwwlzZsAS+OT8Gx6lQ7nUfJQ3lETKT2zxY+fNWyJakr/bzc7D3Mjbp 9Adw==
X-Gm-Message-State: ALoCoQkNZNZLemDPqhuxeXCwIVsks/SjC60Ae27Q98U4VCDNoQWjME8ZusntCPuK48C/6yMTmsR5
X-Received: by 10.50.111.80 with SMTP id ig16mr25843701igb.43.1409094496735; Tue, 26 Aug 2014 16:08:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.104 with HTTP; Tue, 26 Aug 2014 16:07:56 -0700 (PDT)
In-Reply-To: <CAOuvq22QgGVpsxrsZswqspiP-rgNE6B3vp_6bYDTE5-MrLZdVg@mail.gmail.com>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <CACvaWvYHAmpX0f9_m-sckhWz9tcyWA-sxVR4vP-A5UcAQmnYXA@mail.gmail.com> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <CA+cU71k-pLD315dzfd_c74QM51c7V2VQkZ26PiXUTqntmESD=A@mail.gmail.com> <CAOuvq20mZkScvPDKjsa1eZ6rdoHxf_+oF=gpaOcvkOTaYhyj6Q@mail.gmail.com> <CA+cU71mW47OvqRNTbw-H7u-F_k6hMv4xr0XcMYAS_V6eE8brwA@mail.gmail.com> <CAOuvq20C+T9Ejf_KUsfPRtUWL7ggCF0UWJZkGr5xGBEkERXeRQ@mail.gmail.com> <BAY169-DS45D73636AA204DEEABC876AEDC0@phx.gbl> <CAOuvq20kCKk=jcXsy_d8C-4Fn-f0zshP6YUPn5N8hsKt7KO7dw@mail.gmail.com> <CAGZ8ZG3KUPAbePp-_GCztj4RSLd8MuNo1iDz=ua+BEjQVzJc7Q@mail.gmail.com> <CA+cU71=A6vFXZrG8mcqj4uC-z2VdJfFOutqcq9MPTYs+uhpa9Q@mail.gmail.com> <CAOuvq22QgGVpsxrsZswqspiP-rgNE6B3vp_6bYDTE5-MrLZdVg@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Tue, 26 Aug 2014 18:07:56 -0500
Message-ID: <CA+cU71nN-=TjWZZovMUcTrXMF1gBcYFppnfnsaP7hKw+6AUCLQ@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/p1XQlSH1IFXtcAGYAcHZhKTJKbE
Cc: "draft-ietf-websec-key-pinning@tools.ietf.org" <draft-ietf-websec-key-pinning@tools.ietf.org>, Eric Lawrence <ericlaw1979@hotmail.com>, IETF WebSec WG <websec@ietf.org>, Ryan Sleevi <sleevi@google.com>
Subject: Re: [websec] draft-ietf-websec-key-pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 23:08:19 -0000
On 26 August 2014 17:10, Chris Palmer <palmer@google.com> wrote: > OK, so, what do you want? > > Is it even possible for me to write text you would accept? Just because I have a concern or preference doesn't mean I don't really appreciate the work you've done. I do. I'd like PKP-RO to be cached like PKP and applied the same way, absent the connection termination (preference). After I realized the includeSubdomains issue (concern), I want it even more for testing a deployment than I want it for my prior attack detection arguments (preference). I've tried to find all the references someone (e.g. a reviewer) might want changed to do this. My suggestions: ---------- The "max-age" directive is REQUIRED to be present within a "Public- Key-Pins" header field, and is OPTIONAL within a "Public-Key-Pins- Report-Only" header field. Become The "max-age" directive is REQUIRED to be present within the "Public- Key-Pins" and "Public-Key-Pins-Report-Only" header fields. ---------- Note: There is no purpose to using the PKP-RO header without the report-uri directive. User Agents MAY discard such headers without interpreting them further. Become Note: The only purpose to using the PKP-RO header without the report-uri directive is to include a max-age=0 to clear any previously saved PKP-RO directives. After doing so, User Agents MAY discard such headers without interpreting them further. ---------- 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 process the Pins and directives given in the PKP-RO header. If the UA does process 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. Become 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 and process the Pins and directives given in the PKP-RO header. If the UA does process 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. ---------- Upon receipt of the PKP response header field, the UA notes the host as a Known Pinned Host, storing the Pins and their associated directives in non-volatile storage (for example, along with the HSTS metadata). The Pins and their associated directives are collectively known as Pinning Metadata. Become Upon receipt of a PKP or PKP-RO response header field, the UA notes the host as a Known Pinned Host, storing the Pins and their associated directives in non-volatile storage (for example, along with the HSTS metadata). The Pins and their associated directives are collectively known as Pinning Metadata. ---------- It received the PKP response header field over an error-free TLS connection. Become It received the PKP or PKP-RO response header field over an error-free TLS connection. ---------- If the PKP response header field does not meet all three of these criteria, the UA MUST NOT note the host as a Pinned Host. A PKP response header field that meets all these critera is known as a Valid Pinning Header. Become If the PKP or PKP-RO response header field does not meet all three of these criteria, the UA MUST NOT note the host as a Pinned Host. A response header field that meets all these critera is known as a Valid Pinning Header. ---------- The UA need not note any Pins or other policy expressed in the PKP-RO response header field, except for the purpose of determining that it has already sent a report for a given policy. UAs SHOULD make a best effort not to inundate report-uris with redundant reports. be removed entirely. The final sentence is included previously as a SHOULD at the end of 2.1.3 ---------- In Section 2.6: Otherwise, the UA MUST treat this Pin Validation Failure as a non-recoverable error. Become Otherwise, if the Pinning Metadata indicates the policy was not set by the PKP-RO header, the UA MUST treat this Pin Validation Failure as a non-recoverable error. ---------- I believe that Section 2.3.2, paragraph "If a host sets the PKP-RO header..." is clear enough as is. -tom
- Re: [websec] draft-ietf-websec-key-pinning Ryan Sleevi
- Re: [websec] draft-ietf-websec-key-pinning Eric Lawrence
- Re: [websec] draft-ietf-websec-key-pinning Tom Ritter
- Re: [websec] draft-ietf-websec-key-pinning Chris Palmer
- Re: [websec] draft-ietf-websec-key-pinning Tom Ritter
- Re: [websec] draft-ietf-websec-key-pinning Chris Palmer
- Re: [websec] draft-ietf-websec-key-pinning Chris Palmer
- Re: [websec] draft-ietf-websec-key-pinning Tom Ritter
- Re: [websec] draft-ietf-websec-key-pinning Eric Lawrence
- Re: [websec] draft-ietf-websec-key-pinning Ryan Sleevi
- Re: [websec] draft-ietf-websec-key-pinning Chris Palmer
- Re: [websec] draft-ietf-websec-key-pinning Trevor Perrin
- Re: [websec] draft-ietf-websec-key-pinning Tom Ritter
- Re: [websec] draft-ietf-websec-key-pinning Chris Palmer
- Re: [websec] draft-ietf-websec-key-pinning Joseph Bonneau
- Re: [websec] draft-ietf-websec-key-pinning Tom Ritter
- Re: [websec] draft-ietf-websec-key-pinning Joseph Bonneau
- Re: [websec] draft-ietf-websec-key-pinning Trevor Perrin
- Re: [websec] draft-ietf-websec-key-pinning Ryan Sleevi
- Re: [websec] draft-ietf-websec-key-pinning Yoav Nir
- Re: [websec] draft-ietf-websec-key-pinning Tom Ritter
- Re: [websec] draft-ietf-websec-key-pinning Eric Lawrence
- Re: [websec] draft-ietf-websec-key-pinning Ryan Sleevi
- Re: [websec] draft-ietf-websec-key-pinning Yoav Nir
- Re: [websec] draft-ietf-websec-key-pinning Joseph Bonneau
- Re: [websec] draft-ietf-websec-key-pinning Eric Lawrence
- Re: [websec] draft-ietf-websec-key-pinning Trevor Perrin
- Re: [websec] draft-ietf-websec-key-pinning Trevor Perrin
- Re: [websec] draft-ietf-websec-key-pinning Trevor Perrin
- Re: [websec] draft-ietf-websec-key-pinning Ryan Sleevi
- Re: [websec] draft-ietf-websec-key-pinning Ryan Sleevi
- Re: [websec] draft-ietf-websec-key-pinning Tobias Gondrom
- Re: [websec] draft-ietf-websec-key-pinning Yoav Nir