On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir <[email protected]> wrote: > > To summarize, although there has been much discussion since version -06, > most of it did not result in massive changes to the document, so IMO we > don't need another WGLC.
* Weren't we going to discuss the relationship of preloaded to dynamic pins? See email [1]. * The rationale in thread [2] for "strict" seems different from the rationale in previous list discussions [3]. Ryan now argues that "strict" is not needed. I think that's worth considering. * I had feedback on an earlier draft which is still relevant [4], see below. [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html [4] http://www.ietf.org/mail-archive/web/websec/current/msg01692.html FEEDBACK ON DRAFT-07, STILL RELEVANT ==== * 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. * 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, 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 ... "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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
