Hi Chris, all,
There's a few issues that need more discussion:
1) Are SubjectPublicKeyInfos the right things to pin? I suspect the
easiest and safest pin for most sites would be a list of trusted CAs.
Expressing this in HPKP seems difficult and error-prone.
2) Is an HTTP Response Header, sent on every response from a pinned host,
the best way to assert the pin? It's not obvious why this is better than a
.well-known URL, or a response that is only returned if the client asks for
it.
3) Interaction with preloaded pins needs more thought, see email thread
[1].
4) Interaction with cookies needs discussion. Cookie scoping rules pose a
serious problem for pinning, e.g. a pin at "example.com" could be
undermined by a MITM inventing a "badguy.example.com" and using it to steal
or force cookies.
Comments:
* Why is there a "Public-Key-Pins-Report-Only" header instead of a
"report-only" directive? Most of the document is written as if there was a
single "PKP header field", so a directive would make more sense.
* In draft-05, client processing was changed from noting a single "expiry"
value to noting two values: "Effective Pin Date" and "max-age". The
previous approach was simpler, stored less data, and was more aligned with
HSTS.
* Section 2.3.1 fails to update the Effective Date of a noted pin when it
is noted again.
* Section 2.6 mandates "When a UA connects to a pinned Host, if the TLS
connection has errors, the UA MUST terminate the connection without
allowing the user to proceed". HSTS allows the server to specify this, so
it seems unnecessary and inflexible to mandate it here. It's also unclear
whether a "report-only" pin counts as a "pinned Host".
* UA processing rules are confusingly spread across the document. For
example, much of "2.2 Server Processing Model" is actually UA processing.
Also, 2.3.1 and 2.5 describe the same process so should be combined.
* Section 2.5 - Does a failed validation of a "report-only" pin count as
an "error" that will inhibit noting of new pins in the connection?
* Specified UA behavior with multiple header fields is contradictory:
- 2.1.3: "If a Host sets both the Public-Key-Pins header and the
Public-Key-
Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
MUST note only the pins and directives given in the Public-Key-Pins-
Report-Only header."
- 2.3.1: "If a UA receives more than one PKP header field in an HTTP
response message over secure transport, then the UA MUST
process only the first such header field."
* Section 3 - Should the failure report contain the certificates sent by
the server, as well as the validated chain? Could help debugging and
attack analysis.
* Why is SHA1 supported? If the reason is size, why not remove it but
allow the server to pin to a truncated hash (e.g. pin to the first 16 or 20
bytes of SHA256)
* Should there be a list of "excluded" keys that must not appear in the
"validated certificate chain"? Chrome's preloaded pinning supports this,
apparently to exclude 3rd-party subCAs that might have been issued under a
pinned CA.
* Would it be better to use the term "pin" for the entire record
associating (hostname, HPKP data), instead of calling each individual hash
a "pin"? The hostname is "pinned" to the 1-of-n key set as a whole, not
each key individually.
* Should the header name be changed once this draft stabilizes, to ensure
no bad interactions with UAs that implemented earlier drafts?
Minor:
* "Pinning Policy" and "Pinning Metadata" are synonyms?
* 2.3.1 "Known HSTS Host" -> "Known HPKP Host"
* 2.3.1 ... "or," ... "Otherwise" is confusing
* 2.3.2 - are clients expected to store directives they don't understand?
* 2.6 - is pin validation performed on resumed TLS connections?
* 3 - can UAs provide additional JSON fields inside the report?
* The term "validated certificate chain" is not defined
* An IANA registry is needed for directives
* The acknowledgement for "pin break codes" is ancient/irrelevant
Trevor
[1] http://www.ietf.org/mail-archive/web/websec/current/msg01651.html
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
