I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Hopeless. This I-D is a security disaster waiting to happen. It should be thrown away and a radically simpler approach taken. The I-D: part one of an apparently infinite series of documents describing a version of HTTP that is, amazingly, even more complex and impossible to implement than HTTP/1.0. I'm afraid that after the opening sections I decided that further review was a waste of time, but if pushed I might be persuaded. Comments so far: General: way too big. HTTP/1.0 was already far too big, and notoriously impossible to correctly implement. Given how important a piece of infrastructure HTTP is, I'm shocked that a new version seems to not only have failed to simplify the spec, but has grown into a monster that I doubt anyone will ever bother to read, let alone conform to. In my view, the security implications of such a complex spec are severe. We should not be increasing the mess, we should be reducing it. 2.4 Caches As well as poisoning attacks, websites can leave themselves exposed by failing to set appropriate caching values - for example, allowing caches to cache pages containing pesonal information, which is later served to the wrong person. The I-D should discuss this issue and give concrete advice on how to avoid inappropriate caching, whilst still permitting appropriate caching. Likewise, caches can be fooled into serving cached data inappropriaely - for example, in response to a subtly different request. Part 6, which is devoted to caches, appears to give no advice whatsoever. 2.5. Conformance and Error Handling Obviously very important for security. Is littered with vague generalities like "A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false." "Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message)." "When a received protocol element is parsed, the recipient MUST be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined by the corresponding ABNF rules." without giving any concrete advice (other than, presumably, "read and memorise the whole xxx pages of RFCs A, B, C ... Z"). Are there matrices of what is allowed, for example? Where? How long is "reasonable"? What do you do if the length is, in fact, "unreasonable"? I could go on, but I'm afraid the tears will damage my keyboard. No mention at all in Security Considerations. BTW: "A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics." Oh. My. God. 2.6. Protocol Versioning "A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions." Seriously?