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

Ben Laurie <benl@google.com> Thu, 31 October 2013 12:04 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B5C11E8151 for <secdir@ietfa.amsl.com>; Thu, 31 Oct 2013 05:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrH2CxkuwFxg for <secdir@ietfa.amsl.com>; Thu, 31 Oct 2013 05:04:05 -0700 (PDT)
Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FE11E8320 for <secdir@ietf.org>; Thu, 31 Oct 2013 05:04:03 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id oz11so1971408veb.36 for <secdir@ietf.org>; Thu, 31 Oct 2013 05:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.220.186.202 with SMTP id ct10mr1749576vcb.14.1383221043335; Thu, 31 Oct 2013 05:04:03 -0700 (PDT)
Received: by 10.52.183.65 with HTTP; Thu, 31 Oct 2013 05:04:00 -0700 (PDT)
In-Reply-To: <CABrd9STuigKWSz0vyUmXX03gg48nGg4uZPfeG3n-C0=87VGW3Q@mail.gmail.com>
References: <CABrd9STuigKWSz0vyUmXX03gg48nGg4uZPfeG3n-C0=87VGW3Q@mail.gmail.com>
Date: Thu, 31 Oct 2013 12:04:00 +0000
Message-ID: <CABrd9SQapOppywCsCKJebMbLuYfzmU5TkX-_Tv_NZ297zQqrLQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-httpbis-p1-messaging.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-24
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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 <benl@google.com>; 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?