[Resolverless-dns] narrowest possible scope: first-party origin, HTTPS-only + DNSSEC-signed

[nusenu <[e-mail]>]

(I'm quoting from the meeting notes that Patrick sent out [1])

> Paul: We started with "where might we be getting this data"?  Let's 
> limit this to HTTP.
> 
> DKG: I think that an interesting thought experiment would be to 
> define the narrowest possible scope where something like this might 
> be interesting.  If that means "within one tab", HTTPS-only, 
> DNSSEC-signed, hopefully at some point we can find something that 
> doesn't make too many objections, and then maybe we can walk it out.

I support DKG's suggestion of the scope:

DNS data coming from opportunistic sources 
(that is a source that has not been configured as
a DNS resolver)
- MUST be DNSSEC-signed
- MUST be transported via an authenticated HTTPS connection

By that definition anything non-HTTPS is out of scope.

I'd like to clarify the "within on tab" item.
I'd propose to use URL bar origin as a boundary.
That is, if you have two tabs pointing to 
example.com they might share the DNS data learned in either tab.
Should the URL bar origin be the entire FQDN or should it be limited to the SLD?
mail.example.com
www.example.com 
would be the same URL bar origin if we stop at the second level domain.


my motivation for supporting this work:

- decentralization/privacy: 
the configured resolver(s) get to learn less DNS queries,
at the same time we do not introduce new resolvers to the system/application 
(we MUST **never** actively ask webservers from whom we got DNS data
opportunistically for DNS records if they were not specifically configured as resolvers)

I see a privacy+latency win here that is similar to OCSP-stapling where the webserver basically
acts as a reverse-proxy for the user as well.
- fewer networks will be in-path (single endpoint [webserver] vs. multiple endpoints [webserver+multiple auth. NS]) 
when a user visits a website (context: [3])
- has the potential to reduce the hard question of: "Whom should users give their DNS queries?"
since the chosen resolver will get to see less if this is adopted widely (but DNSSEC might become
a limiting factor)
- creates a performance incentive for zone owners to deploy DNSSEC 
- creates a performance incentive for browser vendors to implement DNSSEC validation
- might help reduce tracking opportunities of DoH clients by DoH servers (since they get less data)
- might help in bringing DANE to the web/browser world

- I see a value of this work in the context of privacy focused browsers
like Tor Browser that have already strong URL bar origin isolation [2]
and limited persistent state that might become useful in solving some 
of the privacy concerns this new construct might introduce.


[1] https://mailarchive.ietf.org/arch/msg/doh/jWMuniwu-V4rucpscVlInBAZPWs
[2] https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
[3] https://nymity.ch/tor-dns/


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu