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

"Eric Lawrence" <> Mon, 25 August 2014 18:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 08BC51A01D5 for <>; Mon, 25 Aug 2014 11:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.364
X-Spam-Level: *
X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E0YbgOam0XiF for <>; Mon, 25 Aug 2014 11:07:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0D791A00DC for <>; Mon, 25 Aug 2014 11:07:37 -0700 (PDT)
Received: from BAY169-DS45 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22712); Mon, 25 Aug 2014 11:07:37 -0700
X-TMN: [ShSZKK4Qdaw7yHimgdhk23oT6xwF664o]
X-Originating-Email: []
Message-ID: <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl>
From: Eric Lawrence <>
To: Ryan Sleevi <>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <>
In-Reply-To: <>
Date: Mon, 25 Aug 2014 13:07:36 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CFC065.8A6C0A80"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-OriginalArrivalTime: 25 Aug 2014 18:07:37.0319 (UTC) FILETIME=[73D46770:01CFC08F]
X-Mailman-Approved-At: Mon, 25 Aug 2014 11:35:51 -0700
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 18:25:17 -0000

Thanks, Ryan! A few remarks inline...
> No, PKP-RO is not meant to be cached. In this respect, it behaves similar to Content-Security-Policy's reporting mechanism.
Ah, interesting. I’m curious why not? Is there no use-case for allowing “report-only” pins to be persisted?
If PKP-RO is not meant to persist, then I’d suggest that this sentence should be significantly altered: “If a host sets the PKP-RO header, the UA SHOULD note the Pins and directives given in the PKP-RO header as specified by the max-age directive.” The pins aren’t being “noted” (recorded) anywhere, and “specified by the max-age directive” has no meaning.
Furthermore, saying that “max-age is OPTIONAL within a "Public-Key-Pins- Report-Only" header field.”  implies to me that the intent is that supplying a max-age would have some function.
     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 already accomplish this?

Perhaps?  To me, the “UA MUST NOT note the host as a Pinned Host” suggests that the pin is deemed entirely invalid and no further processing is warranted. That assumption is based on the text that follows:

“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.”

It seems odd to take action based on anything that is not a “Valid Pinning Header.”

Perhaps one of my confusions around the prose is the use of the term “note” as a verb. “Note” could mean “preserve a rule for the future” or it could mean “apply the rule for now and into the future.”

Incidentally, typo: “critera”->”criteria” in section 2.5.

  "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?
> Both are currently allowed.

Interesting. It seems worthwhile to at least note that there’s a benefit of performing the check before the TLS handshake responds to a clientCertificateRequest message.

>>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?
>So the answer is "No, it should be required"

Based on context, I /think/ this was a typo, missing the word “not”? 

  4.4.  Interactions With Cookie Scoping
  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?

Section 4.4 describes how PKP interacts with “Cookie Scoping” but it only describes interaction with SUBDOMAINS of the target host, omitting entirely mention of the scoping of cookies to the target host’s PARENT. It’s unclear why the spec should mention one but not the other.

> It prevents the collusion, so that seems to effectively mitigate that particular attack, does it not?

As far as I can tell, yes, this approach prevents collusion, but only by completely disabling the reportURI feature. There are two possible scenarios:

  Case 1: ReportURI is cross-origin to target. Outcome: UA blocks for privacy reasons.
  Case 2: ReportURI is same-origin to target. Outcome: UA blocks reports to the ReportURI because the ReportURI refers to a host with a failing PKP rule.

Have I overlooked something?