W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

Re: Comments on draft-ietf-http-negotiation-00.txt

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 20 Feb 97 16:20:18 PST
Message-Id: <9702210020.AA06857@acetes.pa.dec.com>
To: Klaus Weide <kweide@tezcat.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2509
To be honest, I haven't really been following this discussion,
and I haven't read the latest TCN draft, but I saw my name scroll
by a few times today, so I thought I should jump in to clarify
a point.

With respect to:
   10.5 Extracting a normal response from a choice response
   For security reasons (see section 14.2), an extracted normal
   response may only be cached if the negotiable resource and the
   variant resource are neighbors.  If they are not neighbors, the
   proxy should reject the choice response as a probable spoofing
   attempt and pass on a 502 (bad gateway) error response instead.

Klaus wrote:
    > >   So there is no need for a proxy to play policeman for exchanges
    > >   in which it may not be involved beyond the usual caching and
    > >   forwarding.
Koen wrote:
    > The general philosophy of the 1.1 caching mechanism is that
    > caches do need to play policeman.  At least that is my
    > interpretation of Jeff's design, the Age header requirements
    > are a good example of this philosophy.  

Klaus wrote:
    But is there a precedent for requiring a proxy *not* to forward a
    response to a client at all, even when it is (a) a valid HTTP
    message, and (b) directly from the origin server?  Note that your
    formulation would require this even of a non-caching proxy.
I don't think it's quite accurate to describe the intention behind the
HTTP/1.1 caching design as "playing policeman".  Probably the most
relevant statement in the HTTP/1.1 spec is
   A basic principle is that it must be possible for the clients to
   detect any potential relaxation of semantic transparency.
but this is somewhat different from saying that caches should
take actions that prevent the transmissions of possibly spoofed

The robustness principle also might be applied here: "be conservative
in what you send, be liberal in what you accept".  In the case of
a forwarding agent (such as a proxy), one might formulate the
robustness principle is "forward everything, but don't hide your
suspicions."  (The requirements for "Age" are basically "don't
hide any suspicions about the accuracy of the Age value.")

Klaus is right that there is no precedent (as far as I know) for
a requiring a proxy to not *forward* a response; most proxies even
forward some kinds of invalid HTTP messages, as far as I can tell.

Since I don't fully understand the TCN design, I'm hesitant to
suggestion a modification, but I think in this case it might
make more sense to use the Warning mechanism rather than convert
a possibly spoofed response into an error.  This would mean
rewriting the paragraph in question to say:

   For security reasons (see section 14.2), an extracted normal
   response may only be cached if the negotiable resource and the
   variant resource are neighbors.  If they are not neighbors, the
   choice response might be a spoofing attack, and a proxy MUST
   attach a Warning XXX (Non-neighboring choice response) before
   forwarding it.  Such responses SHOULD (MUST?) NOT be cached.

I've left the Warning code unspecified because Ari and I still
need to write up our proposed fix to the "WARNINGS" item on the
Issues List, which might involve some revision in the code assignments.

If you could demonstrate that there is no question that this
kind of response is anything but a malicious spoofing attack,
then it might be reasonable to consider a sort of "firewall"
approach to these responses.  But if there is some chance that
it could be used non-maliciously, I think it would be a mistake
to specify in the protocol design that it can't be forwarded.
Protocols are often used in ways that their designers didn't

Received on Thursday, 20 February 1997 16:34:46 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC