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

Ben Laurie <> Thu, 31 October 2013 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7B5C11E8151 for <>; Thu, 31 Oct 2013 05:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VrH2CxkuwFxg for <>; Thu, 31 Oct 2013 05:04:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::231]) by (Postfix) with ESMTP id 1A2FE11E8320 for <>; Thu, 31 Oct 2013 05:04:03 -0700 (PDT)
Received: by with SMTP id oz11so1971408veb.36 for <>; Thu, 31 Oct 2013 05:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=v15lhUiS6QM40Mp8qPk0bOrduShQJSngUEqfFeoWrrs=; b=X1cooEY2dSuGyaMXZBdI0O19gEs5LRO6esSZ/L2dKic487Z8WYA8GovpuOy4YzSc+I 6bqoBXUSxXMeBvcduaXc9lGJsoE/mJ/ByA9iAQ3e0s33B30hg34lwNlzz0A+eurBM2sW bNTTiccZKWE7QzyXTxxMrik1Dse5WVphx6bk5O08Eo/whh4542Bpl6LME2ka9pjNVXZZ VbMmEL3veSnplb8iBSpP3jEyD5dHqRJzW6j1U5BvdAzdvbKwowXJPfn+oi3YanNClN/k nifO+dvPRzg38opss5NeTl101vAnulDvXev9odcQOVUwxYLr2LybehZA5QAkrinBTMkj /6Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=v15lhUiS6QM40Mp8qPk0bOrduShQJSngUEqfFeoWrrs=; b=k+byXj/YGrKWJ66GRRxcDuwdFmk2F+7OcpJkgXR/gq/n/5zrsIRQnBeLiRoWWXIu5b BNchAjnc+7ZtZAj7xzIkT3kCOtnOO/8jP5fZIWw0PYe6kjWPtq62SbU7RuINTDLI9W0R teWOZ72GBjNjlM8L1saaZftDyE+q5+6BeGy9JY3zHXJKSoePK/mJTo73EQvDhF4VjkvN AnzDCZLDb5WXv9oUqZAVDBxaCvjaZrr47K81oPSqvtDOF2lsP/ZDf6Akjd1/Tcx4rFLN jZs/3vattmyZ4idHXzux0PZ7qmFfAdey5oDTM4fDNH+turjOxLfOaMgaPwYcbcCGW002 tn4w==
X-Gm-Message-State: ALoCoQlbBnRuGM5NY0XC1XUlJXzyn0l+EQ/cEDI5qkBos/TrcYqUe17uXlBJR8EZmhOQNamigHv+9mDJG6zcJL0l2mExAbFO1jpPJ4hPd7yjC90FQndGnp2H0wKa1INBwW9mn6XypILcR+csrNWADOijDB1fdlDnFztwAYM2EmBK3iEdcq6z/bXipRofY18098yza7tG2FmZ
MIME-Version: 1.0
X-Received: by with SMTP id ct10mr1749576vcb.14.1383221043335; Thu, 31 Oct 2013 05:04:03 -0700 (PDT)
Received: by with HTTP; Thu, 31 Oct 2013 05:04:00 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 31 Oct 2013 12:04:00 +0000
Message-ID: <>
From: Ben Laurie <>
To: The IESG <>, "" <>,
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-24
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 12:04:05 -0000

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 <>; 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?