In your letter dated Tue, 10 Jan 2023 17:27:12 -0500 (EST) you wrote: >if applications think it is THAT important, they shouldn't be trusting >the EDNS options of a stub proxy, which also might go through an OS >proxy on top. It also cannot trust or know whether the proxy's upstream >forwardering is using encryption either. So it still has to do it itself >if it wants to be sure.
That is an interesting point. Obviously, this is not an issue if the application specifies an encrypted transport to a public DNS resolver. If the application just specifies the need for an encrypted transport but leaves it to the proxy to pick upstreams, then this may become an issue. If this is an issue that needs fixing, then obviously we can extend the description of the options to also apply between a proxy and the proxy's upstream resolvers. >And a draft that specifies a proxy won't change browsers to not do DoH >themselves. Indeed. However, at the moment there is no sensible alternative. This draft provides a way forward. >> The draft does not require a cache, but obviously adding a cache is >> encouraged. > >Now you are not talking about stubs anymore. I'm talking about cache in the proxy. >If applications are willing to trust the local system/proxy, then they >can't get a guarantee about encryption. What if the proxy is stuck on >a network that blocks all DNS except the DHCP obtained ones, and those >you can talk encrypted to, but what does it mean to talk encrypted DNS >to StarBucks ? Talk encrypted DNS to StarBucks means that other customers at the same wifi cannot find out what your DNS requests are. If the application specifies a public DNS resolver and access is blocked, then the user will get some kind of error. In theory a local network can also block port 443. But usually we don't worry about that. >Yes, I agree. But it seems like a sailed ship to me. Similar to how I >don't see why applications/users should follow the ADD proposals that >try to keep you using the local ISP nameserver instead of your own >trusted DoH server. I think this draft is compatible with the ADD proposals. It is just that the proxy would do ADD and applications specify whether they really need encrypted transports are can live with best effort. >The big problem I see is that the application wants end to end privacy >on the DNS queries (or at least end to a large pool to hide in) where >as EDNS is a hop by hop signaling mechanism. You cannot know what >happens when the local proxy sends the query forward. Whether that step >is using encryption is only one step of the chain to keep the DNS query >private. We can send this option on more hops if we think it solves an issue. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
