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

[Julian Reschke <[e-mail]>]

On 2015-07-31 16:52, Charlie Kaufman 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. 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,

I disagree that this is likely.

> 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

That would be one additional round trip with an unclear outcome on 
broken servers. If the additional round trip is acceptable, using 
OPTIONS might make more sense.

> 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

That is true, but I'm not sure what to make out of it. Do you have a 
specific text change in mind?

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782