Hi I have reviewed this draft, and here are some comments.
Section 2.1 last paragraph says that the hash function MUST be sha1 or sha256. This is weird. First it provides no algorithm agility, so adding support for, say, SHA-3 would require a document that updates this one (section 2.4 says so explicitly). Second, SHA2-256 is slower on 64-bit platforms than SHA2-512, so right now some may prefer it. Third, in various locales, some other hash function might be required, such as GOST-34.311-95. I would much prefer that we referred to a registry of hash names ( perhaps this one<http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml> ), and allow anything from there (notably, it doesn't solve the GOST issue). There should be implementation advice advising support of SHA-1 and SHA-256, perhaps even calling them "mandatory to implement", but I don't think we need to require a new spec for updating a list of algorithms. It might also be good to advise on using the same hash algorithm that is used in the signature of the certificate, as the client would be sure to be able to calculate the hash function (or it wouldn't be able to verify the certificate signature. Some of the mandates in section 2 are mixed up. Section 2.2.1 second sentence has "… UAs MUST treat the host …" - clearly a UA mandate. But this is part of section 2.2 ("Server Processing Model"). UA mandates should be somewhere under section 2.3 ("User Agent Processing Model"). Some cleaning up is needed there. Section 2.6 requires the same no-error-or-block behavior here as in HSTS. I wonder if we need this level of strictness, or whether requiring this only for errors involving the verification of pins. IOW, should this document require that expired certificates cause a block, when such policy can and should be communicated via HSTS? Section 2.8 is about pinning self-signed (or self-issued) certificates. Should mention DANE (RFC 6698) type 2 or 3, because those are a more trust-worthy case than normal self-signed or self-issued certificates. Section 4 (security considerations) should have something about why it's wrong to use this header without HSTS. 3rd paragraph of section 1 says that using them together is intended, so we should explain why. Section 5: yes, there are actions for IANA, as they allocate HTTP headers (other than X-something). See the text from draft -14 of HSTS: 15<http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14#section-15>. IANA Considerations Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864<http://tools.ietf.org/html/rfc3864>]. Header field name: Strict-Transport-Security Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): this one A more structural note: The introduction looks a little thin to me. The draft dives into syntax in section 2 before the reader has any idea: * When and why you should want to add this header to your web server responses. What is this defending against * Why you would want to pin an end-entity key, and alternatively why you would want to ping something higher up the chain * What does it mean when there are multiple pins. AND? OR? The third question is answered later in the draft, but I think this information should go in the introduction. And one nit: * The upper-case SHOULD in the introduction seems inappropriate. RFC 2119 labels SHOULD (not sure this is even a pun) be used for cases of interoperability or for preventing harm. Here, the use is the simple English "should", and doesn't mandate anything at all, so it ought to be lower-case: "We propose a new HTTP header to enable a web host to express to user agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs *should* expect to be present in the host's certificate chain in future connections using TLS (see [RFC5246]). Note: this review is with no hats. It is not part of some last-call process. Please treat this as any other review on the list. Yoav
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
