On Wed, 11 Jan 2023, Philip Homburg wrote:
Obviously, this is not an issue if the application specifies an encrypted
transport to a public DNS resolver.
At that point you are fighting ADD proposals. You are fighting the LAN
preferences, the wireless carrier preferences, the OS and maybe the
user. What order of preference of override or vetoes are involved?
What does the application do when their request is denied? Tell the user
the connection failed or reluctantly use whatever DNS transport is
available?
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.
That would just be a list of promises that cannot be verified. How does
an application know the proxy or the proxy's forwarder actually plays by
those rules? (we had another WG trying to codify these policies in DNS
too, but still you can't find out if these statements are truthfull).
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.
I disagree it is a way forward. But will step back and let others have
their say in this discussion.
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.
Right, you are talking about replacing stubs for DNS recursive servers|proxies.
I mean, I wish we could. I tried for 10 years at Red Hat to make that
the new default. But the issues with captive portals are very difficult.
Talk encrypted DNS to StarBucks means that other customers at the same
wifi cannot find out what your DNS requests are.
Well, WPA2/WPA3 is already protecting me from other customers. And while
those protocols could be attacked with lots of resources, I don't think
that targetted attacks at Starbucks is the real threat here. The real
threat has been proven to be wifi/hotspot providers that go out of their
way to monetize on targetted advertising and finding out your identity.
They break hotspot detection functions because devices sandbox hotspot
logins, and that prevents them getting facebook tracking cookies. So
they purposefully mislead and allow captive.apple.com to "work" so those
devices think they are not in a captive portal and give out their
non-sandboxed user cookies.
See also my recent post to ADD about Canadian Wireless Carriers doing
nationwide support of advertisement trackers.
As I said in ADD, the best use case is to never ever let the local
network tell you what DNS to use. That is the mean reason I don't see
this proposal as useful. The second reason is that I want my OS to
always prefer encrypted DNS over non-encrypted DNS, and encrypted DNS
to known parties over encrypted DNS to unknown parties. I hope to be
able to configure that OS-wide and not per-application. I wouldn't
want to send out EDNS queries into the network to change my preferences
on this.
That is, using this draft would just mean applications always signal
"use encrypted DNS to this specific DNS provider", something I think
makes just more sense to configure once for your OS and not per
application.
If the application specifies a public DNS resolver and access is blocked,
then the user will get some kind of error.
So either it breaks too often and people turn it off, or you have to
have a dialog with the user, and I don't think users can anyway so
anything more than "well use whatever other DNS then".
If you have applications that are so sensitive that it may never cause
an unencrypted DNS packet, you should really use a VPN on that device.
That would also protect you from the local network / region from seeing
which IP (from your private DNS answer) you are connecting to.
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.
Does ADD or the application trump in case of conflicts? Because ADD
insists on trumping those decisions.
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.
There is no chain of verifiable trust there. The user simply cannot know
what any DNS server in the chain will do with its query or answer. So I
don't think it solves any issue.
As I said, I'll step back now and let others voice their views.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
