RE: ID: Proxy autoconfig

Expanding on my previous idea we could actually use the URL in DHCP to
direct us to a "services server". Once there we can then interrogate the
resource specified by the URL to get such interesting things as
autoproxy scripts. These scripts can contain all sorts of fascinating
information, such as time outs on the script's lifetime as well as
provisions for how to get updated proxy information. Rather than filling
DHCP up with endless URLs for every service, why not just use it as an
entry point?

		Yaron

> -----Original Message-----
> From:	jg@pa.dec.com [SMTP:jg@pa.dec.com]
> Sent:	Tuesday, April 08, 1997 1:39 PM
> To:	Yaron Goland
> Cc:	Stuart Kwan; http-wg@cuckoo.hpl.hp.com; josh@netscape.com
> Subject:	RE: ID:  Proxy autoconfig
> 
> I talked to Jeff Schiller (IETF area director for security)
> about the serverloc security problems....
> 
> The problem is that anyone, anywhere, can advertize the service, and 
> potentially arrange to get a client to use a service (in this case,
> a proxy) of the attacker's choosing.
> 
> The security compromise for serverloc to go to proposed standard is to
> allow one, via public key crypto, verify the new advertisements.
> 
> The problem from our point of view is that the solution to serverloc's
> 
> security problem reduces to the previously unsolved problem: having to
> 
> distribute different keys to different browsers, which isn't better
> than 
> what we have now, having to distribute the first proxy configuration 
> information to the browser. A solution to this might be to use DHCP to
> 
> distribute the keys required, but is not yet specified.
> 
> Now, DHCP has its own set of security problems, but I note that people
> are already trusting it in the first place to get their IP addresses
> (for the
> mass market).
> 
> So without being expert at either protocol, it sure sounded like in
> the short term a DHCP based solution might be best, though in the
> longer
> term, something that is more dynamic than just information acquired
> at boot time would be a better solution (so that when a browser
> gets restarted, you can pick up the current proxy, or fail-over if a
> failure
> is detected while talking to a proxy.  And in the long term, this may
> not be either/or.
> 
> Hope this helps discussions....
> 				- Jim

Received on Tuesday, 8 April 1997 17:31:33 UTC