[secdir] secdir review of draft-ietf-httpbis-cice-01

Charlie Kaufman <charliekaufman@outlook.com> Fri, 31 July 2015 14:52 UTC

Return-Path: <charliekaufman@outlook.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0D8501A896E; Fri, 31 Jul 2015 07:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lu5bnXa3ARPD; Fri, 31 Jul 2015 07:52:20 -0700 (PDT)
Received: from BAY004-OMC2S19.hotmail.com (bay004-omc2s19.hotmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6974F1A8971; Fri, 31 Jul 2015 07:52:18 -0700 (PDT)
Received: from BAY167-W85 ([]) by BAY004-OMC2S19.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 31 Jul 2015 07:52:18 -0700
X-TMN: [JEndHmVC+8Fh9J6bNdL2LprQUnFucEdU/F4+1klYqH0=]
X-Originating-Email: [charliekaufman@outlook.com]
Message-ID: <BAY167-W850D7002182FE6F2CA216CDF8A0@phx.gbl>
Content-Type: multipart/alternative; boundary="_24e52a2c-3627-4740-8241-1ec52fa68101_"
From: Charlie Kaufman <charliekaufman@outlook.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-httpbis-cice.all@tools.ietf.org" <draft-ietf-httpbis-cice.all@tools.ietf.org>
Date: Fri, 31 Jul 2015 07:52:17 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Jul 2015 14:52:18.0249 (UTC) FILETIME=[7F2B3B90:01D0CBA0]
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/tTqrW9m15ISLKEdCb8fGFr5Wy7w>
Subject: [secdir] secdir review of draft-ietf-httpbis-cice-01
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 31 Jul 2015 14:52:23 -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.

This pleasantly short document proposes a small extension to http whereby a server indicates to a client what encodings of the payload sent with the request would have been accepted, and is aimed mainly at allowing clients to learn whether the server supports gzip compression. I agree with the authors that the addition of this information does not introduce any new security considerations. The information retrieved must be considered only a "hint" because the acceptable encodings can change at any time without notice, so the values returned are not a fully reliable indicator of what encodings will be acceptable on a subsequent request.

There are some challenges associated with this method of delivering a configuration hint. As the document notes, the acceptable encodings might not be global to a server, but rather might vary for different resources on the same server, or even with different request methods for the same resource. In practice, clients are likely to guess the encodings supported according to responses it has received for other resources and methods on the same server. If the client guesses wrong, it might end up wasting bandwidth by sending some large payload uncompressed when it could have been compressed or - worse - compressed and subsequently uncompressed when the initial request is rejected.

One way to avoid this possibility that might be worthwhile if the payload were large enough would be to first make a request with some "known bad" encoding specified and an empty body. When the server rejected the request based on the bad encoding, it would specify what encodings were acceptable. If would be architecturally cleaner is there were some reserved encoding name that could be guaranteed never to be valid, though in practice clients could choose an encoding name like UNSUPPORTED or INVALID and be pretty confident no one would ever standardize that as an encoding name.

While this specification recommends that the Accept-Encoding header only be returned on successes and on failures where the problem was an invalid encoding, clients can never count on that behavior because implementations that don't implement this specification will never return that header even if it is a problem with the encoding.