Re: [Int-area] New version of WPADNG

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 <joshco@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-leave@ietf.org
>