Hi Josh, I agree with you that the world has changed a lot since WPAD was defined in 1997. The Web has changed, and the use of proxies has changed with it. Now that HTTPS is ubiquitous, transparent caching proxies are pretty much extinct and proxies are mainly used for either filtering or privacy benefits. In both of those scenarios, there exists a trust relationship between the client device and the proxy service. And that relationship is used to configure proxy settings: modern browsers and operating systems offer enterprise controls that allow an administrator to configure a proxy on their entire fleet without requiring any automatic discovery. Similarly, privacy proxies are configured by the privacy service that runs on the client devices. There isn't much of a need for automatic discovery. And such discovery causes harm: we've seen time and time again how attackers were able to leverage WPAD to gain access to confidential data. Because of these two combined factors, many browsers and operating systems have disabled WPAD by default. Your WPADNG proposal addresses neither of these factors, and doesn't change the fact that WPAD is unsafe and no longer needed. At this point in time, I think we can pour one out for WPAD, declare that its time has passed, thank it for its service, and move on.
Cheers, David On Mon, Jul 8, 2024 at 5:35 PM Josh Cohen <jos...@gmail.com> wrote: > Greetings, > > > > I've submitted a new draft of Web Proxy Automatic Discovery Next > Generation (WPADNG) > > https://www.ietf.org/archive/id/draft-joshco-wpadng-01.html > > > > *Changes:* > > > I've removed the old DNS A TXT, SRV discovery mechanisms > > > > The current discovery mechanisms are DHCP (v4/v6), and DNSSD. > > > > In terms of priority it is DHCP then DNSSD. > > > > For DNSSD the key is new _wpadng._tcp.example.com. DNS "devolution" > remains, eg: first "dev.example.com" then "example.com" > > > > I've added the use of a URN for the proxy config URI to indicate "there is > no proxy and stop discovery" to prevent discovery of rogue proxies. > > > > *I'm seeking feedback on the following:* > > > > Is the priority of DHCP, DNSSD best? > > > For DNSSD, is domain devolution common practice? Eg, eg: first " > dev.example.com" then "example.com". If not, what are other common > practices to deal with subdomain scenarios? > > > For DNSSD and DHCPv6, we can include more than just a URL, since we have > key/value pairs in DNSSD and from my read, it looks like there is room to > do the same for DHCPv6. Is there other information the client should know > that we should add? > > > > Are there other URNs that we should add? > > > > -- > > --- > *Josh Co*hen > > _______________________________________________ > Int-area mailing list -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org