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

Ben Laurie <benl@google.com> Wed, 18 December 2013 18:02 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359F91AE052 for <secdir@ietfa.amsl.com>; Wed, 18 Dec 2013 10:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFA5Aqic_mmh for <secdir@ietfa.amsl.com>; Wed, 18 Dec 2013 10:02:24 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E41911AE037 for <secdir@ietf.org>; Wed, 18 Dec 2013 10:02:23 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jw12so5527518veb.31 for <secdir@ietf.org>; Wed, 18 Dec 2013 10:02:22 -0800 (PST)
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=tYT78oBN6RbQvo3kIpXvpHX7xMPe04RY9pLwglGvgYw=; b=if9aJwzwLryyOgjCB9aODJQd3I6k1njZKVaW+3NAagP58nrd0BJli9X+h2Dc+aXzJf +doQrYKSfZUdZowrNcex4pnqXMS1IVYH4wNCOGMTA/Q3u/zdNMuWAPetbIcFnlSHYMP3 zwH9bYdA7ZQAJJfeOc6MIgc4CAu4cyXXAKLDiUPV4JtEW+7nCqumCsjkq7YYeRioQCFj N9gnZHbQc/mkyccLU2bzEhX2O67/r7ZrYUfh5mWK2Kwr4qWcFIcq6+XnoVaMuaFV32l0 VGrRJlZXanRRh73CSb/exyAMsMLgD/cw4nUdef9YIT7J5Xvqz5BFshwylbOtFLLhncnq gPTw==
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=tYT78oBN6RbQvo3kIpXvpHX7xMPe04RY9pLwglGvgYw=; b=DtRm4qxg9IbTr4kTQ44EbASrCXadTmjZ1qhsZbKlIYkK41kt9pTqWw7J2Tw7VkZESN 8+wCZ13Ef439jUbuq3ZzZ1N0ZUmpLkToXS8PeJHAfpTLf1434n14MeA9Ezk2ECVUsgko w+7Jz3i+F/elHtlffUQJAvdM00Y8HYM5kp2aJ2qMsE5jmwb+mdTTx4Jyf2g7kk1hLcYq gmFhaMESJJKPOrPM9ONHt0TNFOpz6u5plt5TxV6kDzM/TukMMW0Vz+OexSfBS15XN6XS B4WliUEvUTvwbelA7JbCx/h4JgkS7QowdN5n9+fsooYx5e3g1rMi/xTUepFpsmpWawfq QIvg==
X-Gm-Message-State: ALoCoQmIW+Ch+BQFSIBB0HUMMgV4tuU+rIUmcuTSaMKqj5Ray3U7v6BOGFFQy+PYeBrqjVctgJymlDeDfl6Kw6zxk9X7nCFKcgLGug8MxY3lyqTJ5TZA/8Sq+RhRhkPWt5FggW730KyplkUZJfyuZDFBNe1e8Crf3MpVS+NwvXYqhPiMC9RL9WOOkieQauY+v+xxpBpd3qzp
MIME-Version: 1.0
X-Received: by 10.58.108.196 with SMTP id hm4mr9165304veb.28.1387389742025; Wed, 18 Dec 2013 10:02:22 -0800 (PST)
Received: by 10.52.183.65 with HTTP; Wed, 18 Dec 2013 10:02:21 -0800 (PST)
Date: Wed, 18 Dec 2013 18:02:21 +0000
Message-ID: <CABrd9SS-R7s4U7_tRGuV2mNgxKnW9mhk=AboNcUxFEAZSLPnbA@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="UTF-8"
Subject: [secdir] secdir review of draft-ietf-httpbis-p1-messaging-25
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Dec 2013 18:02:26 -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: HTTP/1.1 is complicated, with many pitfalls. The draft does
not give a great deal of assistance in dealing with them, and, indeed,
encourages s/w to trip over these pitfalls.

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, other than applications should "emit appropriate
Cache-Control response header fields".

It also, strangely, blames cache poisoning on implementation flaws,
whilst exactly those types of flaws are encouraged in the next section of this
I-D: "Unless noted otherwise, a recipient MAY attempt to recover a
usable  protocol element from an invalid construct."

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

As mentioned above, dangerous behaviour is encouraged on the part of
receivers - i.e. to attempt to make some sense of invalid constructs.

Also, "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." is a
licence for arbitraty behaviour.

No mention at all of any of this in Security Considerations.

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." - more
encouragement to ignore the spec, and doubtless introduce yet more
interesting security flaws.


3.  Message Format

"A recipient that receives whitespace between the start-line and the
first header field MUST either reject the message as invalid or
consume each whitespace-preceded line without further processing of it
(i.e., ignore the entire line, along with any subsequent lines
preceded by whitespace, until a properly formed header field is
received or the header section is terminated)." - ditto.

3.1.1.  Request Line

"Recipients of an invalid request-line SHOULD respond with either a
400 (Bad Request) error or a 301 (Moved Permanently) redirect with the
request-target properly encoded." - ditto.

3.2.2.  Field Order

"A server MUST wait until the entire header section is received before
interpreting a request message, since later header fields might
include conditionals, authentication credentials, or deliberately
misleading duplicate header fields that would impact request
processing."

Good advice, but sadly, no substance - it goes on to say:

"A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma.  The order in
which header fields with the same field name are received is therefore
significant to the interpretation of the combined field value"

Which gives no useful advice about "duplicate header fields that would
impact request processing", and worse, means that intermediates and
endpoints have essentially no chance of predicting the behaviour of
machines up/downstream from them.

3.2.4.  Field Parsing

"A server that receives an obs-fold in a request message that is not
within a message/http container MUST either reject the message by
sending a 400 (Bad Request), preferably with a representation
explaining that obsolete line folding is unacceptable, or replace each
received obs-fold with one or more SP octets prior to interpreting the
field value or forwarding the message downstream." - again,
encouraging dangerous behaviour.

3.3.2.  Content-Length

Oddly, advice is given on what to when multiple identical content
lengths are received, but not when they're different...

"If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body
length or forwarding the message."

(though the next section does say what to do: for a change, reject
it).

"Since there is no way to distinguish a successfully completed,
 close-delimited message from a partially-received message interrupted
 by network failure, a server SHOULD generate encoding or length-
 delimited messages whenever possible.  The close-delimiting feature
 exists primarily for backwards compatibility with HTTP/1.0."

Surely closed connections _can_ be distinguished from interrupted
ones?

4.  Transfer Codings

It should be noted that compressed encodings lead to vulnerability to
CRIME-like attacks.

9. Security Considerations

In general, a few useful pointers are given, but the above suggests
rather more is needed.

However,

"Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem."

a) Users are not going to read this document, so - how are they to be
made aware?

b) No mechanism to determine who might be running intermediaries is
described.