[secdir] secdir review of draft-ietf-httpbis-p1-messaging-24

[Ben Laurie <[e-mail]>]

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?