I think the root of confusion here is that bootstrapping mechanisms like DHCP, and perhaps PvD, are sometimes being used among mutually-trusting parties, sometimes among mutually-distrusting parties, and often somewhere in-between. Configuration elements that make sense in one of these contexts are often unusable in the other.
I think the best solution is usually to move the configuration element out of these multi-use protocols, to a single-purpose system where this kind of conflict doesn't arise. In this case, that might mean a BCP that says "transmit your PAC file URL through your device provisioning channel". If the information must be conveyed in a "dual use" channel like PvD, it may help to emphasize that the information is only to be used for networks that the client regards as sufficiently "trusted". --Ben Schwartz ________________________________ From: Josh Cohen <jos...@gmail.com> Sent: Thursday, July 18, 2024 12:37 PM To: Watson Ladd <watsonbl...@gmail.com> Cc: David Schinazi <dschinazi.i...@gmail.com>; int-area@ietf.org <int-area@ietf.org>; ietf-http...@w3.org <ietf-http...@w3.org> Subject: Re: [Int-area] New version of WPADNG Lots of good info here. Bernard said: In RFC 5505, the IAB took on this question, separating basic IP configuration (which has in practice proved difficult to secure) from application-layer configuration (which can be postponed until later Lots of good info here. Bernard said: * In RFC 5505, the IAB took on this question, separating basic IP configuration (which has in practice proved difficult to secure) from application-layer configuration (which can be postponed until later in the boot process when security facilities are available to secure it). Through the lens of RFC5505, that leads towards DNSSD. Is DNSSD considered safer than DHCP? Paul said: * It's necessary for edge devices to securely learn the security policies of a network, for example a proxy if any and the cert or will offer if so. We're working around DoH policy signaling using the DNS server itself but it's slow going. I read the Mozilla support pages for DNS over HTTPS (DoH): Are you involved with this Mozilla work? https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https<https://urldefense.com/v3/__https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https__;!!Bt8RZUm9aw!7DnECYLfc3Kw-CB-cs9W6Q6AgTvTEDFIU_d1Dpiiwc6r8wiAIhvPFPRxgPxs8oDBtq0LDvI32Q$> https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet<https://urldefense.com/v3/__https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet__;!!Bt8RZUm9aw!7DnECYLfc3Kw-CB-cs9W6Q6AgTvTEDFIU_d1Dpiiwc6r8wiAIhvPFPRxgPxs8oDBtq0cyQm1KA$> The solution to detect when not to use DoH is a canary domain: use-application-dns.net<https://urldefense.com/v3/__http://use-application-dns.net__;!!Bt8RZUm9aw!7DnECYLfc3Kw-CB-cs9W6Q6AgTvTEDFIU_d1Dpiiwc6r8wiAIhvPFPRxgPxs8oDBtq2RIFdfbw$>. Can you shed light on this choice vs DHCP or DNSSD? Paul said: * I'd like to be able to verifiably inform each connecting device about the network owner's policy demands so that the device can decide whether to accept those terms or remain offline. Tommy Pauly said: * I do think there is room for network-discovered proxies, and I’d like to continue to explore how to do that safely in the realm of the PvD-based discovery. I think the cases are going to be more limited there — cases of the network saying “I have this proxy I suggest using because it is well-optimized for my network, if it’s on your trusted list of proxies, then please use it"… >From what I've read of PVD a network's preference for DoH could be expressed >in a PVD. A network's PVD could be discovered by either DHCP or DNSSD On Thu, Jul 18, 2024 at 9:29 AM Josh Cohen <jos...@gmail.com<mailto:jos...@gmail.com>> wrote: On Wed, Jul 17, 2024 at 11:00 PM Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>> wrote: On Wed, Jul 17, 2024, 7:36 PM Josh Cohen <jos...@gmail.com<mailto:jos...@gmail.com>> wrote: > > You lost me with the nuclear submarine reference. I'm guessing instead of a > terminal room, the IETF now has a navy? https://en.m.wikipedia.org/wiki/USS_Jimmy_Carter<https://urldefense.com/v3/__https://en.m.wikipedia.org/wiki/USS_Jimmy_Carter__;!!Bt8RZUm9aw!7DnECYLfc3Kw-CB-cs9W6Q6AgTvTEDFIU_d1Dpiiwc6r8wiAIhvPFPRxgPxs8oDBtq30-AGPQA$> She wasn't made for sitting around. > > The coffee shop gives you your IP address, default route to the Internet, DNS > servers and other DHCP options. It often has a captive portal, which may also > have a transparent proxy that filters, can eavesdrop or otherwise abuse you. > It is *their* network after all, you are just a guest. That's aside from > chai latte sipping wifi snoopers and the general jungle of public wifi. So what's WPAD doing here? It's just another way to get that traffic to the wrong place. Again, the Internet threat model has the network be untrusted. That might be bad news for the vendors of devices that don't work that way, but that's what the RFC and design says. And indeed the coffee shop router shouldn't be trusted. I am having dejavu. We had a similar debate 25 years ago. Proxy servers in general weren't exactly popular because they violate the end-to-end ethos. With respect to the network being untrusted, enterprises will push back on that. They will do things that seem draconian. > > > I'm definitely getting the "WPAD suxorz" vibe, but what's missing are answers > to how scenarios WPAD currently addresses will be addressed without it. > > At work, your computer uses your enterprise's proxy. When you arrive at the > coffeeshop, will you go into your computer's settings and turn off the proxy? > When you go back to work the next day, will you go back into your settings > and turn it on again? I think this scenario is due to some fundamental confusion. What is the enterprise proxy doing? Why is it safe to turn off that function at the coffeeshop or entrust it to some random person given the computer will be back on the network the next day? And if the enterprise network needs to administer hosts, it can do that through much better ways. I was assuming a situation where the enterprise proxy is not accessible from outside of the enterprise network. > > > > On Wed, Jul 17, 2024 at 7:50 PM Watson Ladd > <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>> wrote: >> >> One adversary is willing to devote an entire nuclear submarine to the >> task. They are more than willing to use existing vulnerabilities in >> ways that you never hear about because they are good at their jobs. >> >> If you use network links to configure your device, and the device goes >> to the coffeeshop, that coffeeshop gets to configure the device. >> That's just inherently a bad idea, and always has been. >> >> Sincerely, >> Watson Ladd >> >> -- >> Astra mortemque praestare gradatim > > > > -- > > --- > Josh Cohen -- --- Josh Cohen -- --- Josh Cohen
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
