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

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

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
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/tTqrW9m15ISLKEdCb8fGFr5Wy7w>
Subject: [secdir] secdir review of draft-ietf-httpbis-cice-01
Precedence: list

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.

--Charlie

[secdir] secdir review of draft-ietf-httpbis-cice… Charlie Kaufman
Re: [secdir] secdir review of draft-ietf-httpbis-… Julian Reschke