RE: LYNX-DEV two curiosities from IETF HTTP session.

On Wed, 10 Dec 1997, Jim Gettys wrote:

> 
> >  From: Yaron Goland <yarong@microsoft.com>
> >  Date: Wed, 10 Dec 1997 11:21:51 -0800
> >  To: "'jg@pa.dec.com'" <jg@pa.dec.com>, Josh Cohen <joshco@microsoft.com>
> >  Cc: Foteos Macrides <MACRIDES@SCI.WFBR.EDU>, lynx-dev@sig.net,
> >          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> >  Subject: RE: LYNX-DEV two curiosities from IETF HTTP session.
> >  
> >  I doubt any commercial browser will implement 305 without some very serious
> >  security provided to assure that the proxy asking for the one time redirect
> >  is going to get it. I would suggest that this problem needs to be dealt with
> >  in the large 305/306 context, in a stand alone spec, and that the draft
> >  standard for HTTP should simply state that 305 has been deprecated and
> >  SHOULD NOT be implemented.
> >  
> >  	Yaron
> 
> I think you are confused....  In Rev-01, only an origin server is allowed
> to generate a 305 response.  It is authoritative for that resource, so

But what is there about the protocol which allows this requirement to
be enforced?

> the spoofing problems don't come up (and is the reason for that text being
> in the document...)

Seems to me that the protocol relies on gentle (i.e., conforming)
behavior by proxies and servers. The definition of spoofing includes an
element of malicious intent.

Perhaps it would close the loop to require that the client only 
accept a 305 status from an origin server to which it is directly
connected?

Then the potential for spoofing would be limited to IP and/or DNS
spoofing.

In either case though, I fail to see the motivation for someone
intending to spoof a redirect who wouldn't simply change the
origin server or make the IP spoofed variant of the origin server
simply serve the nefarious content which would have be acquired
as a result of the redirect.

Thus I don't see any difference in risk with/without 305.

Dave Morris

Received on Wednesday, 10 December 1997 17:11:18 UTC