Re: [Int-area] New version of WPADNG

[Ben Schwartz <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, July 18, 2024 12:37 PM
To: Watson Ladd <[e-mail]>
Cc: David Schinazi <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:


On Wed, Jul 17, 2024 at 11:00 PM Watson Ladd <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Jul 17, 2024, 7:36 PM Josh Cohen <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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