[websec] Richard Barnes' Yes on draft-ietf-websec-key-pinning-19: (with COMMENT)

["Richard Barnes" <[e-mail]>]

Richard Barnes has entered the following ballot position for
draft-ietf-websec-key-pinning-19: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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