Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-21

I agree with Pete's comment about the first sentence.

It would be nice if in Section 5 or 7 some suggestion could be made for UAs to consider the relationship between the functionality they provide to clear pins/pinned hosts and the functionality they provide to clear (or prevent the storage of) other UA state. E.g., upon clearing one's browsing history or entering private browsing mode, it seems like having the option to clear pins/pinned hosts or not pin would make sense. This is alluded to in Section 7 but not really tied to the threat described in Section 5.

I'm also curious about whether there is any reason to retain expired pins? (Other than the fact that flushing them requires the UA to actively check which ones are expired.)

This is an important document, and overall clearly written.  There are a few points that it would be good to clean up.


Introduction: "At least one UA..."

FWIW, this is now "At least two UAs..."  Firefox also has a manual pin list as of version 32, currently in Beta.


Introduction: "but is possible to pin keys without requiring HSTS"

-> "but it is ... and vice versa."


Section 2.2.2. "Pinned Hosts SHOULD NOT include..."

This applies not just to Pinned Hosts, but to any web host, right?


Section 2.3.1. "If a UA receives more than one PKP header field ... only the first PKP-RO header field (if present)"

This seems problematic in light of the fact that HTTP recipients are allowed to coalesce the values of multiple header fields.
http://tools.ietf.org/html/rfc7230#section-3.2.2

So, for example, if header coalescing were done at a lower layer in the HTTP stack than HPKP, then the pinning code wouldn't be able to distinguish "first" vs. "rest".  On the other hand, maybe this is a use case for using semicolons as separators, since the combined header field would not be valid.  In either case, there's a need for updated text.


Section 2.5. "at least one Pin that does NOT refer to an SPKI in the certificate chain"

I understand the motivation for this, but this doesn't actually force the site to have a backup pin -- they can just make up a pin value.  It seems like it would be more effective to make the recommendation in Section 4.3 stronger.


Section 4. "Security Considerations"

Most of these seem more like "Operational Considerations" or "How-To-Not-Brick-Your-Site Considerations".  :)

Thanks for clearing up my discuss points. One possible
remaining nit though:

- In 2.2 you say: "(1) the processing rules for HTTP
   request messages received over a secure transport (e.g.
   authenticated, non-anonymous TLS); "

Should the "e.g." be an "i.e." ? It's probably fine either
way but just wondered.

-- OLD comments below, didn't check 'em

abstract and elswhere: SubjectPublicKeyInfo doesn't usually
have spaces between the terms. No big deal. After the abstract
would a ref to 5280 be right for SPKI as well?

general: I think emphasising the backup pin requirement in the
intro would be good. It's a little hidden now and would be a
surprise to some I bet.

2.1 - pin-directive has the literal "pin-" but later you say
(in bullet #3) that directive names are case insensitive.  Does
that apply to "pin-" as well or not? 

2.1 - has some typos: reistry and hahs

2.1 - "Known Pinned Host" would be a fine term to define in a
section 1.1 that was renamed via s/Requirements
Language/Terminology/

2.1.1 - max-age is really defined against the time of reception
and not (in principle) from when its emitted?  I know that
makes no difference now, but with a sufficient latency (e.g.
Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage
is showing:-) it could, just about. I think to be pedantically
correct, max-age ought be defined versus the time of emission
and not receipt.

2.1.2 - uses the term "Pinned Host" which is not the same as
the previously used "Known Pinned Host" - is the distinction
meant to be significant or is that a typo?

2.1.3/section 4 - shouldn't the potential DoS issues be
discussed for cases where report-uri != same-origin? E.g.  if
busy-site.example.net (is hacked and) sets report-uri to
victim.example.com (maybe with some HTML/JS that generates
loads of queries to the victimj) that'd be like getting /.'d I
think that's maybe worth noting in the security considerations
or in 2.1.3 where you (quite properly) say to rate-limit
reporting. If you'd rather not say why though, that's ok too.