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. 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. * "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
