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

["Eric Lawrence" <[e-mail]>]

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 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#section-2.1.3 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?


thx,
Eric