On May 1, 2014, at 12:41 AM, Trevor Perrin <[email protected]> wrote: > On Mon, Apr 28, 2014 at 11:24 PM, Yoav Nir <[email protected]> wrote: >> >> Having reviewed this, I think this version addresses all the issues raised >> during WGLC. > > The added sentence in 2.7 on preloaded/dynamic pins doesn't match the > rest of the text, which is written to mandate specific behavior. If > we're not going to discuss implementation alternatives, we should just > delete most of 2.7 and let implementations do what they want.
Why? All the new sentence says is “The Effective Pin Date of built-in pin lists is UA implementation-defined”. Implementations are still required to treat the pre-loaded pins as though they have some effective date and determine precedence by whichever has a later date. Suppose Chrome will have a pin list that is downloaded from Google every hour. What date is assigned to the pins in that list could be part of the format, or it could be assumed to be a week old, depending on how Google updates this file. > The text in 2.3.2 on PKP-RO doesn't really match the rest of the doc. > Most of the draft is written as if there is a single header, set of > Pinning Metadata, and "Known Pinned Host" state. But 2.3.2 doubles > those things, which causes many minor ambiguities, e.g.: > > * 2.2.1 - "a Pinned Host SHOULD include in its response exactly one > PKP header field" > > * 2.3.1 - "the UA MUST process only the first such header field" > > * 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? (or > new "report-only" pins)? > > * 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". It's unclear whether a "report-only" > pin counts as a "Pinned Host" for the purpose of other TLS errors. > > The draft could use an editing/cleanup pass to clarify all this. > > Also, some of the issues I've been bringing up since July need to be > addressed: > > * Interaction with cookies needs discussion, at least in security > considerations. 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. While there are similar concerns, I don’t see the interaction. If you are example.com, and badguy controls badguy.example.com, then they’re going to get your example.com cookies unless you can block it with scoping. HPKP doesn’t help you there. You *can* block them with HPKP if their control on badguy.example.com relies on a mis-issued certificate and you restrict them with the includeSubdomains directive. > > * "Pinning Policy" and "Pinning Metadata" are synonyms? > * 2.3.1 ... "or," ... "Otherwise" is confusing > * 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
