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

Ben Laurie <benl@google.com> Wed, 30 October 2013 17:41 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 A9B7911E8248 for <secdir@ietfa.amsl.com>; Wed, 30 Oct 2013 10:41:20 -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 w+p0qSD1n-KG for <secdir@ietfa.amsl.com>; Wed, 30 Oct 2013 10:41:20 -0700 (PDT)
Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id DFC7621F9FB7 for <secdir@ietf.org>; Wed, 30 Oct 2013 10:41:19 -0700 (PDT)
Received: by mail-vb0-f52.google.com with SMTP id f13so1234624vbg.25 for <secdir@ietf.org>; Wed, 30 Oct 2013 10:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+RuQIFZS35zDGwGUfHvVzKq/wbiAb6cB/rRfzRufoFQ=; b=Th94RB5BewV/hfkXM8Xa6tiLy+pSWVKV/Xi5eoNo3EguY3GuFiMJw2GX8i7wdi5RvM AITRAVn4YKYCSKGyGg8vVPD4i1d6FHbRvaotNHhP8wzsHEuWL5R5I7p6gfb5OVhfELD9 rpRrto7/JMXarP7Uozh/ULzMCs4WZq40voQ9G/b58z4+Zd/H/vmrt7MxRpTrzv/okOmU /HqROwO21COZdVKYB+9GFl7d00tbjQZcTqg5EoYq5Y3HxpbdRur5zrLRX/5aJ/bzejCQ tUbS7fZU/8+clTd+64k8Y55tURgfj3CC3H7PjsTtpHLTjFRa19nOiJgeanNBmPrbwh77 xx1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+RuQIFZS35zDGwGUfHvVzKq/wbiAb6cB/rRfzRufoFQ=; b=epMFGEirfDCEnVSrhdET+1bwDNEe78sRkebTF9Q6snv5ZBlBnsOWx9Hy7gIMegI+ms JjNF/OTZs1qO7sC9egLHr5UrDlUjOhQtvx4HiIRTjWIAKtsCWaQYShW7NYh+niSM1WHX lxDK/FGRuWk4oc9nhKF0jlXkp5tUTJ1JoHiuB8liA3u1iXBB/RAOpkZRDns7EBG7QlDt mvVDPimXuIDsZfcKokkeuQ6ePMrWP9sR5s6vWx2QXuDPZ+e7tsmtBDiXKDAIZQ4+Umic 5prjqerij8SS67/AWwpBtbP8qsZHD+QsmMr4N+z9zNi03tYuVbl54+ckHAaGz/tAIyGO yFSA==
X-Gm-Message-State: ALoCoQkBgLFnE7N4WtqtR4rZdfLCBmmC5qox/fGDY1qmzHbqZ90PI9zW535Nn9nptKdwASxqCN6kaB+Jfjp3zJpiy/jcu/V0hy8ki2krawfsgpN+9caYgzrzCuKWT4YEpx+00iRb82v08VmyFLx1H8TMwUhvMaiM7odJom+keHzYHiV4+h+KMSw9s+paKbpKK64Mg2rAjoO7
MIME-Version: 1.0
X-Received: by 10.58.75.164 with SMTP id d4mr48097vew.53.1383154879315; Wed, 30 Oct 2013 10:41:19 -0700 (PDT)
Received: by 10.52.183.65 with HTTP; Wed, 30 Oct 2013 10:41:19 -0700 (PDT)
Date: Wed, 30 Oct 2013 17:41:19 +0000
Message-ID: <CABrd9STuigKWSz0vyUmXX03gg48nGg4uZPfeG3n-C0=87VGW3Q@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: [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: Wed, 30 Oct 2013 17:41:20 -0000

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?