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

[Ben Laurie <[e-mail]>]

Apologies, I managed to confuse myself into thinking this was a revamp
of HTTP, rather than an update to the existing spec.

I would hope a revamp would address the serious structural issues and
hence my harsh criticism.

Now that I've realised this is, in fact, a revision of the existing
spec to reflect experience, I retract this review. I do feel, however,
that the text is lacking in solid actionable advice, and so I will
re-review in light of my corrected understanding.

Thanks for not flaming me!

On 30 October 2013 17:41, Ben Laurie <[e-mail]> wrote:
> 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?