Re: [websec] draft-ietf-websec-key-pinning

Ryan Sleevi <> Mon, 25 August 2014 06:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 98D801A8A63 for <>; Sun, 24 Aug 2014 23:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.046
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SzPTVPBxEuvT for <>; Sun, 24 Aug 2014 23:03:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7935B1A6FBA for <>; Sun, 24 Aug 2014 23:03:51 -0700 (PDT)
Received: by with SMTP id ik5so14711163vcb.34 for <>; Sun, 24 Aug 2014 23:03:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id cu4mr3233979vdd.62.1408946630647; Sun, 24 Aug 2014 23:03:50 -0700 (PDT)
Received: by 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: <>
From: Ryan Sleevi <>
To: Eric Lawrence <>
Content-Type: multipart/alternative; boundary="001a1134cc686d7cc305016df30f"
X-Mailman-Approved-At: Mon, 25 Aug 2014 01:24:12 -0700
Cc:, "<>" <>
Subject: Re: [websec] draft-ietf-websec-key-pinning
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, 25 Aug 2014 06:03:54 -0000

On Fri, Aug 8, 2014 at 1:50 PM, Eric Lawrence <>

>   Comments on
> -------
> 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?

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

> -------
> 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

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:
> 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.


> 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