Re: [websec] draft-ietf-websec-key-pinning
Ryan Sleevi <sleevi@google.com> Mon, 25 August 2014 06:03 UTC
Return-Path: <sleevi@google.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D801A8A63 for <websec@ietfa.amsl.com>; Sun, 24 Aug 2014 23:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzPTVPBxEuvT for <websec@ietfa.amsl.com>; Sun, 24 Aug 2014 23:03:51 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7935B1A6FBA for <websec@ietf.org>; Sun, 24 Aug 2014 23:03:51 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id ik5so14711163vcb.34 for <websec@ietf.org>; Sun, 24 Aug 2014 23:03:50 -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=5T5UJU8svgWvod9x9ioIxTYmpTxDoXd0N9xfC3Ps0NE=; b=Hi1tUIWTNZlQ5gDCTRFuELE1/tx5peSXaa/HxRiBp8ZsoKQYkpLZyoG+k/uveVjD6n Wvb64AsnSQTx1JyJ/u1qfrgolLB0YQs/UVYbBWmmfJckBU7R5ZX0nJ0WxrGoYjgPzzI/ 7q8Cm6CNC5m7WmWalmYOIClm+v+7NQHS4AwuGgpeVUwZeD5q9o+V6RmQdSRvYCsGV/04 kUTix605/7FjCvFHdgusx1WACMBQJjrSXVzxexyXCOzr1JOXnqri3YpHnzzv3UeV3Mbf nOW9bkdxYv8N/qnLxNk+NIruEfmbWMQrw6EHbAjhMdXxJNwWkrWT/eDQgdUfrc1DxIcY iysw==
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=5T5UJU8svgWvod9x9ioIxTYmpTxDoXd0N9xfC3Ps0NE=; b=bKI7ptAjXzIIJQl7tCjhAB11C36QZ6SgWO38ErcdfzeHZ7at3kPcH5X7roaiNmyHGe wTU9nN3NSpp4R4oz00C+MS3sflwxG8OV7X47LY8TEpSgQHp/tGFYOsI+xGpQMgggM/Fk Lb+/XaTD1T6Fp40LfGR9+PqLmKC5INK0+Yzgk4486NC0W2tf7anX1cN3+HgUCkU9cd5I lDciQAtKcIE1gJsKTJktYsnc8+x5bejlXfL0a2AvD9gRZAPliuC55BSsyCT61vteryYo gYQHnsMTflrxitMWVV5D8xBwNnIzO7Izwm7npj/vPI1quNMwfSmRAVqWqEak1PxJ1PjA b0uA==
X-Gm-Message-State: ALoCoQlZxBY/JxljjvEGX2VgSaVIsh3JX5ANbpbg8Z+SY4mSP0874t8Ut94suKYfRDX+ZREY6cf3
MIME-Version: 1.0
X-Received: by 10.53.6.132 with SMTP id cu4mr3233979vdd.62.1408946630647; Sun, 24 Aug 2014 23:03:50 -0700 (PDT)
Received: by 10.52.119.178 with HTTP; Sun, 24 Aug 2014 23:03:50 -0700 (PDT)
In-Reply-To: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl>
Date: Sun, 24 Aug 2014 23:03:50 -0700
Message-ID: <CACvaWvYHAmpX0f9_m-sckhWz9tcyWA-sxVR4vP-A5UcAQmnYXA@mail.gmail.com>
From: Ryan Sleevi <sleevi@google.com>
To: Eric Lawrence <ericlaw1979@hotmail.com>
Content-Type: multipart/alternative; boundary="001a1134cc686d7cc305016df30f"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/CCfDiV6Jx2XW0qlciinbu7n4EaY
X-Mailman-Approved-At: Mon, 25 Aug 2014 01:24:12 -0700
Cc: draft-ietf-websec-key-pinning@tools.ietf.org, "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [websec] draft-ietf-websec-key-pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 06:03:54 -0000
On Fri, Aug 8, 2014 at 1:50 PM, Eric Lawrence <ericlaw1979@hotmail.com> wrote: > Comments on http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20 > ------- > In several places, the text seems to suggest that PKP-RO rules are not > intended to be cached within the UA. Is that the case? If so, this isn't > explicit; max-age should be forbidden. > > In contrast, if PKP-RO rules are allowed to be cached within the UA, then > the following should be removed: > > 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. > > ... because the site may wish to disable a previously-cached PKP-RO entry. > No, PKP-RO is not meant to be cached. In this respect, it behaves similar to Content-Security-Policy's reporting mechanism. I'm not sure if you're suggesting forbidden - such as treating the header as ill-formed, ergo not sending a report - or merely ignored. I feel like #6 of Section 2.1 already reflects this, but would be happy to add specific text directly stating that max-age is IGNORED for PKP-RO. > > ------- > 2.3.1. > > RO header fieled > - > typo, fieled->field > > ------- > 2.5 > 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. > - > If the failing criteria was "cert chain didn't contain at least one of the > SPKI signatures", should this trigger a report to the report URI to aid > developers and/or enable some amount of protection for sloppy attacks (or > captive/corporate MITM interception, etc) against 1st-time visitors? > Doesn't http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.1.3 already accomplish this? When used in the PKP or PKP-RO headers, the presence of a report-uri directive indicates to the UA that in the event of Pin Validation failure it SHOULD POST a report to the report-uri. If the header is Public-Key-Pins, the UA should do this in addition to terminating the connection (as described in Section 2.6 <http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.6>). > > ------- > 2.6. Validating Pinned Connections > When a UA connects to a Pinned Host, if the TLS connection has > errors" > - > This probably should be "connects to a Pinned host using TLS connection" > since PKP does not require that the user connect via a secure connection. > Thanks, yes. > > ------- > "If the connection has no errors, then the UA will determine whether > to apply a new, additional correctness check: Pin Validation" > - > Should this wait until the TLS validation has fully completed, or should > it happen before the client potentially responds to a > clientCertificateRequest from the server? > The implementations are already consistently-inconsistent in this respect. That is, both Chrome and Firefox do this during certificate validation, but for timing reasons, certificate validation occurs at different times. Both are currently allowed. > > ------- > For example, a UA may disable > Pin Validation for Pinned Hosts whose validated certificate chain > terminates at a user-defined trust anchor, rather than a trust anchor > built-in to the UA. > - > Might it be useful to explain the motivation here, however briefly? I'm > super-happy to see this here (Fiddler!), but most UAs don't have trust > anchors built-in, they rely on the operating system to provide them. > > Well, this was merely meant as one representative example, not necessarily a normative recommendation. That is, one could equally add "For example, a UA without built-in trust anchors may also decide to ..." and still be consistent with the normative SHOULD - that is, the examples are non-exhaustive. Still, happy to expand this text further, as I suspect this is just an unintentional use of restrictive terminology (i.e. a UA can do this even when it defers to the OS trust store) > ------- > The UA MUST ignore superfluous certificates in the chain that do not form > part of the validating chain. > - > As far as I understand things, there can be multiple valid chains to > multiple roots. Should the validation procedure be required to check each > possible candidate chain? > Neither RFC 5280 nor RFC 5246 require UAs to evaluate all candidate chains. Indeed, there's enough controversy from parties in TLS that I suspect there is not clean resolution in either event. In the UA sphere, not all UAs consider candidate chains. Mozilla Firefox, before version 31 (implementing mozilla::pkix) did not consider all candidate chains. 31+, it does, and it does the pinning check during the evaluation of potentially valid candidate chains. Google Chrome defers to the OS for the chain building, which OS X does not consider candidate chains, but Windows does. However, Windows lacks a suitable means for calling back on evaluating candidate chains. As a result, Chrome performs validation after the candidate chain has been declared "successful". So the answer is "No, it should be required" > > ------- > locally-installed anchor > - > This should probably be "user-defined trust anchor" to match the earlier > prose. > > ------- > "served-certificate-chain": [ > pem1, ... pemN > ], > - > Privacy: This could leak organizationally-private information; say the > user's company is using BlueCoat or another intercepting proxy with > interception certificates that contain data that should not leave the > organization. > Funny that this spec would consider the privacy of the attacker (as such situations are indistinguishable from an attack on the pins). Still, happy to call it out specifically. > > ------- > "include-subdomains": include-subdomains, > - > This field could be misleading, as the JSON report contains the hostname > that the user visited, which may differ than the host that originally set > the rule if include-Subdomains was set on that rule. > Good point. This suggests that the JSON may need to indicate both the target hostname and the source (of the PKP data) hostname. > > ------- > indeed could pin to issuers not in the chain > - > Per the spec, they indeed MUST include a pin to an issuer not in the chain > > ------- > 4.4. Interactions With Cookie Scoping > - > I'll mention that IE sends cookies to subdomains even when a domain > attribute isn't present. Q3: > http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx > > This section suffers from the same incompleteness that Section 14 of the > HSTS spec suffers: Because a rule specified on a subdomain > (effective-third-level-domain) does not apply to the > effective-second-level-domain, if a user visits the 3rd-level domain first > or exclusively, a MITM attacker can perform a cookie-injection by > generating a phony insecure request to the effective-second-level-domain > and returning a Set-Cookie header in his poisoned response. > I'm not sure I understand your remark with respect to "incompleteness". This is more of an operational guidance for server operators, correct? > > ------- > 5. Privacy Considerations > "UAs MAY, therefore, refuse to send reports outside of the origin that set > the PKP or PKP-RO header." > - > 1. It seems odd to put a mitigation inside a description of the attack. > Per Stephen's DISCUSS, I think we'll be bringing this mitigation 'out' a level in the spec. > 2. Doesn't the proposed mitigation inherently failure-prone, since the > report would inevitably fail, because the origin's PKP rule would block the > report? > It prevents the collusion, so that seems to effectively mitigate that particular attack, does it not? > > ------- > 5. Privacy Considerations > "Conforming implementations..." > - > 1. This 3rd privacy attack should be bulleted as a separate point. > Agreed > 2. Earlier, it's stated that PKPs should be stored in "non-volatile > storage". In practice, I would expect UAs would ignore attempts to update > PKP/PKP-RO rules while in their respective "Private Mode"s. Is that the > expectation of the authors? > Update the non-volatile storage? Yes, that's what a UA would likely do. Prevent updates to volatile storage? No, just as UAs in such modes traditionally allow a degree of volatile storage (since the modes are primarily meant to prevent disk persistence, rather than tracking). This allows, for example, session cookies to work. > > Thanks! > > -Eric Lawrence >
- 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