Session 1: Measurement of Encrypted DNS

Oblivious DNS over HTTPS (ODoH)

  • Plaintext, traditional DNS (Do53) is the most widely used variant of the DNS protocol (92% of traffic seen at 1.1.1.1)
  • However, Do53 leaks information about user traffic on the network
  • DoH encrypts stub-to-resolver traffic. However, resolver operators can still associate queries with clients, enabling them to profile clients
  • There are a number of additional problems in DoH today: centralization, privacy by policy, and regulatory concerns
  • Key goals of ODoH: address association of queries to clients, and privacy by policy
  • Key insight of ODoH: de-couple client IP addresses from the DoH queries they issue
  • ODoH protocol (simplified)
    • Client encrypts query name, wraps it in a DoH query and sends it to a proxy node, which terminates an HTTPS connection with the client
    • The proxy node then forwards this query to a DoH resolver or Oblivious target on behalf of the client
    • Once the proxy node receives the response, it sends the response back to the client
  • Important considerations
    • Clients need to choose proxy nodes and target resolvers that are not operated by the same entity
    • Clients need to have some level of certainty that proxy nodes and target resolvers are not colluding
  • Proxy nodes can see client’s IP address, but not the contents of the query
  • Target resolver can see query contents, but not the client’s IP address
  • Performance measurement setup
    • Three public resolvers: 1.1.1.1, 8.8.8.8, and 9.9.9.9
    • 90 client stub resolvers, 10 per vantage point
      • 7 Google Cloud datacenters in the western/central/eastern United States, 1 datacenter in Montreal, and 1 datacenter in San Paulo
    • Experiment: 21,000 DNS requests per day (15 per minute)
  • DNS response time measurements
    • Takeaway 1: important to choose low latency proxy/target resolver pair
    • Takeaway 2: re-use connections
      • Connection re-use improves median DNS response time performance by 48%
    • Takeaway 3: co-location between proxy/target resolver results in better performance
    • Takeaway 4: compared to DoH, average query response times increase by 100% without co-location, and 50% with co-location
  • In-browser measurements (page load times)
    • PLTs increase by ~20% compared to Do53 without co-location, and 13% with co-location

Measuring DoT/DoH Blocking Using OONI Probe

  • OONI is a platform for measuring Internet censorship. Measurements performed from more than 200 countries.
  • The platform is collaborative in that users install a tool called OONI Probe to run measurements (desktop app, mobile app, CLI)
  • Motivation for measuring DoT/DoH blocking
    • States are increasingly asserting their power of sections of the Internet that they control
    • If I’m a user querying a domain name that I “should not be” with an ISP resolver, then I may not get the correct response
    • DoT and DoH should help avoid this DNS-based censorship in theory, so it’s important to see whether or not DoT/DoH are getting blocked in practice
  • DNSCheck experiment
    • Step 1: Bootstrap a DoT/DoH service. If the resolver URL contains a domain name (not something like 127.0.0.1), resolve the domain name using the client’s system resolver, and see if you get an IP address or an NXDOMAIN. Add the result to the set of known IP addresses.
    • Step 2: Lookups. For every IP address we discover (plus ones we knew from beginning), try to connect to this IP address, do TLS handshake. If everything is successful, send a query and record a reply.
  • Measurements
    • Dec 15th, 2020 - Jan 10th, 2021
    • 123 DoT/DoH services measured. This presentation focuses on DoH over TCP only
    • Used an experimental CLI client (miniooni)
    • Presentation focuses on three vantage points: Kazakhstan (AS48716), Iran (AS197207), China (AS45090)
  • Main findings
    • dns.adquard.com resolved to 10.10.34.36 in IR
    • Most endpoints fail or succeed with lookups consistently
    • 1.1.1.1:853 and 1.0.0.1:853 were blocked and unblocked frequently in KZ
      • Same for 1.1.1.1:853 in IR
    • dot://dot-jp.blahdns.com was unblocked in CN around Jan 1st, 2021
    • [Presentation included success/failure rates by vantage point in a table]
  • In KZ, most blocked resolver was Cloudflare (91% DoT, 88% DoH)
  • Most common cause of failure in KZ was timeout after TLS handskae
  • Most common cause of failure in IR was timeout during TLS handshake
  • Most common cause of failure in CN was TCP connection timeout
  • SNI-based blocking occurred in KZ for DoH
    • cloudflare-dns.com: 99% failure via timeout after TLS handshake
    • mozilla.cloudflare-dns.com: 100% success
  • Future work
    • Make DNSCheck available to all OONI Probe users, rather than just miniooni users
    • Study DoH over QUIC blocking
    • Study whether Encrypted Client Hello reduces blocking
    • Study the fingerprints of popular TLS implementations

“No Port 53, Who Dis?”; a year of DNS over HTTPS over Tor

  • Alec and his partner have exclusively used DNS over HTTPS over Tor for over a year. It worked marvelously, and he forgot that he set it up.
  • It’s a system that is meant to provide additional privacy guarantees to your DNS queries.
  • Concern: latency is going to be terrible.
    • Median latency for Alec: 262 ms. Goes up to 464 ms if you disable caching.
    • Some people live with worse performance, day-in, day-out.
  • Some people are willing to trade off latency for other values, e.g. privacy.
  • Arguing about 5 ms vs. 50 ms vs 500 ms is an act of tech privilege. Minimum latency isn’t everything.
  • If you accept this persepective, you may instead think about latency in terms of a budget.
  • DoHoT was designed to address a privacy-invasive threat model based around actors who..
    • May surveil network links
    • Block queries
    • Tamper with queries
    • Learn that my identity was/is associated with certain queries
    • etc..
  • Traditional DNS (Do53) risks all of these threats.
  • DoT, DoH, ODNS, ODoH risk some of these.
  • DoHoT risks arguably none of these, unless Tor relays become severly compromised.
  • Setup
    • Copy of dnscrypt-proxy configured as stub
    • Presented to the LAN as a DHCP Do53 service
    • Configured to make all resolution requests over Tor via SOCKS
    • Used a load-balanced pool of public DoH servers
  • Takeaway: please stop thinking of latency as cost. Please consider it a budget to offer value.

Q/A / buffer time discussion

  • Oblivious DNS over HTTPS (ODoH)

    • Q (Paul Hoffman): Who are the users of this protocol, given that it is a larger and more fragile protocol than Do53/DoT/DoH? Who would not trust their immediate upstream resolver to profile but would trust them to collude with their resolver?
      • A (Sudheesh Singanamalla): One way to ensure that entities don’t collude is to have some Mozilla-like organization that vets resolvers (logging resolvers, non-logging resolvers, etc) so that users can make informed decisions.
      • A (Chris Wood): Anyone who is interested in adopting DoH also consider the resolver to be malicious. ODoH in a way fills in the gap that DoH left.
    • Q ([?]): How do you limit the metadata leakage of DoH, e.g. a rogue resolver wanting to associate clients with queries?
      • A (Sudheesh): If there was a rogue resolver that wanted to identify what the client was doing, they could send a unique IP address and see who connects to that IP address. However, that’s outside the security/privacy guarantees of the protocol itself.
    • Q ([?]): Would it be better to use proxy nodes in a round-robin fashion to limit any concerns related to associating a user (or set of users) with a proxy?
      • A (Sudheesh): This issue should not occur is many users are using a proxy. However, if there are very few users using a proxy, it could be indirectly possible to associate a proxy to a user.

  • Measuring DoT/DoH Blocking Using OONI Probe

    • Q (Allison Mankin): Are you generally using TLS 1.2 for measurements? You mentioned TLS 1.3 specifically on one data point.
      • A: We manually ran some measurements with TLS 1.3 to see whether outcome changed, and it did not change the outcome.
    • Q (Sara Dickinson): Am I correct in thinking that you ran some measurements in India that produced slightly different results?
      • A: We did some measurements in India. IIRC, there was no blocking in India.
    • Q (Ulrich Wisser): There was so much blocking w/ Cloudflare. Is that because the IP is allocated from a research network?
      • A: QUIC for 1.1.1.1, which means it was possible to route to this address.
    • Q (Puneet S.): I represent Google DNS. It was surprising that 8.8.4.4 worked but 8.8.8.8 didn’t work. Do you have any thoughts on that?
      • A: Censorship is not consistent. Every network has its own set of rules.
    • Q ([?]): Did you only use one VPS in KZ? Is the blocking specific to certain ASes or country-wide?
      • A: In KZ, we used two networks. One was a VPN and another was a VPS, but we stopped measuring with the VPN because nothing seemed to be blocked. Thus, it was unclear whether or not the VPN was actually located in KZ. Anecdotally, the structure of blocking is centralized, though.

  • “No Port 53, Who Dis?”; a year of DNS over HTTPS over Tor

    • Q (dkg): Can you characterize the typical workflow for people on the network that this was deployed on? When you say this is liveable, what does that mean? Presumably due to lockdown there’s not very many people in your house.
      • A: Domestic environment for me and my partner. They connect to DHCP who gives the IP address of the resolver. The resolver runs on a Raspberry Pi. Not sure whether you would roll this out in a coffee shop or have everyone run this on their laptop independently.
    • Q (Chris Wood): I want to drill in on the threat model. You’re assuming an NSA-inspired actor that can use endless compute to track down what a client is doing. However, this threat model doesn’t seem to scale. If every client was using something like ODoH, do we think there is enough resources available to track down what every client is doing?
      • A: I’m skeptical of this, too. However, there is a waterhole attack for DoH/ODoH, in which you log everything, throw it into an Oracle bin, and perform an analysis when you need to.
    • Q (Paul Syverson): My understanding is that Tor browser does not currently support DoH. This raises a learning curve/usability issue. How steep of a learning curve do you think is setting up DoHoT, and are you working on this?
      • A: I am not working on this because it’s a home setup thing right now. It’s hardly like I’m investing in it right now. I greatly encourage people to work on this and experiment on their own accord. However, because we have something like DHCP which literally tells people which resolver to use, the only additional thing I had to do was setup a firewall to ensure that no Do53 queries get leaked. You could easily turn a DoHoT service into an appliance.

  • Misc questions

    • Q (Paul Hoffman): It seems like everything discussed so far requires users to have a certain level of understanding about privacy/latency tradeoffs. Doesn’t that go against everything we know so far about users? Who are we designing these protocols for?
      • A (Alec Muffett): I’ll turn that around: are we designing protocols only for speed demons, or people who want to achieve some other goal? Some people use Tor browser because they want some level of privacy. They are willing to accept latency tradeoffs. I don’t see that as elitist or discriminatory; it is offering value for people that are trying to solve a particular issue.
      • A (Sudheesh Singanamalla): It may seem like these protocols are designed for people who know exactly what they’re doing, but that’s how protocols like HTTPS came into place. Most people don’t even know that HTTPS is in place right now, due to the big push that was made by the [networking/privacy/security] community. I suspect something similar will happen with DNS. I don’t think users are dumb; they clearly know what they want and what they’re doing.

Session 2: Civil Society, Usability and DNS

DNS Privacy Vs

based on a paper

  • 4 Goals: confront tensisons between privacy protest, tradeoffs between privacy and other considerarions, a lot of researches are needed.

  • Abstract:

    • make DNS lookup more private for the user affects internet mearsurements
    • DNS cencership

  • DNS privacy is a big win as a public interest. Two fondational docs: RFC 6973, RFC 8280.

  • Measurement:

    • Public interest benefits: 1) knowlede of network perf and op are inportant 2) empower users as consumers, 3) monitor bad behacvious. However, it comes at the cost of user pvivacy and 2) M is harder when user data is private (e.g., DoT, DoH)
    • The research question is Which resrarch methods will work and not work with private DNS. Does user choise have impact, e.g, DoT, DoH?

  • Consolidation

    • public interest concern 1) eco detrimental 2) degrades quality of services 3) slows innovations 4) single points of failure 5) facilitates mass surveillance 6) complicates regulatory jurisdiction. But there is huge market like browsers to adopt private DNS and the early adopator have better business model
    • The key question is does ubiquitous adoption of private DNS resolve consolidation?

  • Abuse

    • public interest benefit: mitiagte abusive behavior and lemitigate restrictions at the content layer
    • But more private, more hard to mitigate

  • Shutdowns

    • public interest concern: internet shutdowns violate the rights to free expression, access to information, and assembly.

  • Next steps:

    • adk for feedbacks in GitHub
    • inlcude “Vs Usability and Accessibility”
    • Make more distinctions between DoH, DoT and others
    • find publication

Censored Planet

  • From a paper published in CCS 2020
  • Internet censorship (e.g., certain web sites are blocked) is pervasaive and evaolving
  • The measure is very complex, cen mathos variance, geo and network variance, logtitudual varians
  • previous studies, few contries
  • Direct cen mesurement platform (direct measurement), limitatiaons: scales, coverage, continuity, syn, ethics
  • Remot cen measurement
    • techs: Augur, Iris, Satellite, Quack, etc
  • Iris, Satellite are used to measure DNS manipulate, compare answers from control resolvers and test resolvers
  • Satellite Scals (8.2.M OpenDNS resolvers in 232 countries). To reduce risk, only use infra resolvers (30k resolvers in 175 coutries)
  • To resolve the Limitations of remote, Censored Planet was introduced
    • launched in 8/2018
    • 95,000 vp in 221 countried
    • 21.8b meausremnts in 20 months
    • 8 ASes/ country
  • Modular Design
    • Input scanner selects vantange point, test list
    • Interference scanner: scheduler, health monitoring
    • Data Pre-propessing: aggreate data, false positive
  • Censorship analysis
    • censorship values vary within coutries
  • Time series analysis: anolmoly detection , trend analysis
  • Findings
    • 15 event, 4 reported, 10 unreported.
    • Trends DNS censorship in more than 100 countries
  • Some countries DNS filter of COVID-19 related websites (e.g., China, Iran), but most websites are not malicious.
  • Data is publicly available

When DNS Goes Dark: Understanding Privacy and Shaping Policy of an Evolving Protocol

  • based on a TPRC paper
  • The question is as the protocol evoles, do the privacy preserving extentions enhance user privacy?
    • between clients and ISPs
    • browsers
    • public DNS operators (google, cloudflare, 75% of the resolver market): more orgs don’t want to maintain their own DNS resolvers
    • EFF, cdt, (NGO)
    • Who are looking our for the user privacy?
  • despite DoH, DoT, ODoT, someonce has access to a users’a DNS lookups
  • DNS and PII:
    • Is IP addess PII? most legal regulations in EU, US: IP by itself may not be PII, but if the IP can be linked be linked to a household, then it’s PII
  • examined 12 DNS providers (e.t., google, dclouforce)
    • 9 had privacy polies (6 has DNS policies), other 3 do not have privacy policies
    • examine the 6 providers under the GDPR articles - legalally read (10-30minutes)
      • GDPR Article 5(b): Purpose limititations, not clear that whether it’s ok to share data for profit.
      • 5(c): Data minimization. The generak policies are too board, cover all sevices, not specific to DNS
      • 5(e): Storage limitations: DNS only privacy policies are far more stringent than general privacy policies.
      • Artical 7: Conditions for consent: consent is a gray area. The question is what does the content mean?
      • Article 45: Data transfers on the basis of adequacy:

User Expectations and Understanding of Encrypted DNS Settings

  • encrypted DNS is not often “on by default”. And trustes recursive is also selected by default.
    • What are the defualt settings?
    • Do the users understand it? Do the users lnow how to change?
  • Different web browsers have different UIs to enable DNS-over-HTTPS. Hard to find.
  • Choosing a trusted recursice also differs by web browsers
  • pilot survey:
    • do users unstead what DNS setting options do?
    • How do users interact with current DNS setting options?
    • Why do users choose the seeting that they do?
    • findings:
      • people do change the default setting if they knew how
      • people had limited knowledge of DNS privacy
  • preliminary: 15 users in survey via prolific, plan for larger survey
  • changing setting in Firefox
    • some are not willing to change
  • choised of encrypoted DNS setting? Automatic?
    • People make different decisions if they know more about the encyrpted DNS
  • People more ISP, but most do not know NextDNS cloudflare, Quad9
  • Main findings:
    • stick with defualt settings
    • don’t understand differene options
    • some peiple change options when they have more info
  • Future steps:
    • larger sample size
    • more extensive interface testing

Q/A / buffer time discussion

Talk 1:

  • Paul Hoffman: good research, DNS privacy introduces some problems. Benefit the entire DNS community.
    • A: present the public interests. Needs to be acceptable bu non-tech peeple, but the it needs to tech reasonable
  • Ram: Shutdown, 2019, Iran blocked internet. had their own internet. intranet?
    • A:
  • Vijay: just a comment: where to publish, (regulation, law): TPRC could be a good fit, legal comm (e.g., senatros), technitians
  • paul Syversion: anybody designs the protocol in an overall
    • A: please contribute to the paper on GitHub

Talk 2

  • Do your DNS measurements cover encrypted DNS protocols as well?

    • A: not included, to add. DoH

  • Vijay Gurbani :slide 25, russian is under estimated

    • A: number of vp, limit selection: only select infra/org vp. throw some potential vp, all countre 10,000 vps

  • Paul Syverson: Tricky questions: people trying to get good, e.g., COVID information out there might be inclined to block anything that is known/validated. Horrible from a censorship general use perspective. Smart and good public protection in quick use of available resources perspective. Response?

  • More speech is not better speech

    • A: the covid ones are not malicious in various secrutiy categories. It might not be a good idea to block all the related covid-19 websites

  • Pallavi: was any investigation done to determine if RPZ for some of the open resolvers might be a contributor to the censorship.

    • Will be covered at the end of the day

Talk 3:

  • Benno Overeinder: slide 14: did you look at 9.9.9.9? They don’t collect IP, they transfer IPs to geo location.
    • A: didn’t. but none of the provider listed in the slide had policy about data transfer. Although some providers said they no storage, they do have retention periods.

Talk 4:

  • Murtuza Jadliwala: I am assuming your study targets users who know what DNS is. A sizeable internet population doesn’t know what DNS is or what it does. So how representative these results will be of the entire Internet user population?

    • A: didn’t assume people know DNS. The survey started with questions of DNS and encrypted DNS.

  • DKG: similar thing about HTTP and HTTPs consolidation?

    • A : a paper about cwarling the DNS. but not awrare of paper HTTP and HTTPs consolidation.

  • Sandra Siby: additional info provider to users to make decision?

    • A: not from specific provider, just text what is encrypted DNS, optunistic mode. A lot people chose to stay worring phone may not work if they change the mode.

  • Sudheesh Singanamalla: Super interesting work. Do you think there’s an interesting opportunity towards the education aspect of privacy to have some sort of a landing page like the ones during browser updates to show users some explanations of what their settings could mean and suggestions to switch any settings if necessary?

    • A: firefox has a popups when it changed to DoH defult. An education page can be very helpful. The firefox changed the popups during the survey - added more information.

Session 3: Novel work, ADoT and Future Research

Programmable In-Network Obfuscation of DNS Traffic

Liang Wang about this in-progress paper Do53 traffic reveals sensitive information Encrypted DNS methods put trust in public DNS resolvers, use a strategy of keeping the IPs of the queriers away from the public DNS resolvers. One solution is to use proxy-based solutions such as Tor or ODNS - no party can see the query and the source IP at the same time. This adds some issues to the deployment - introduction of latency or performance bottleneck. Also, configuration and user effort may be needed - adds learning curve or possibility of error.
Suggestion: programmable network, upload a policy about the source IP into it. It has good performance properties. Do not need to make it do all the encryption work - which it may have some limits for - convert the source IPv4 to an IPv6 address. Encrypt the IPv4 address in the IPv6 address. Do not need cooperation with clients etc.
PINOT sits at border of IPv4 network. PINOT encrypts the source IP in each packet individually. After encryption, the source IPs are meaningless to parties outside the network.
Challenges include limitations of the programmable switch in PINOT - need to not put a packet through the pipeline only once, otherwise this hits too hard on throughput and latency. Decided to use a crypto algorithm that allows for this restriction, two-round Evan-Mansour. Not as secure as AES, but it is hard to break, and they think it is sufficient for this application - see the paper for details. Using IPv6 to allow the ciphertext to be put into the packet - use in the source IP address. Can’t use another field due to routers modifying along path. PINOT stores the encryption keys only. It is stateless.
Reserved IPv6 prefix is used Deploy at multiple ingress and egress points in the network. DNS traffic can leave the network from any egress point. Good for connectionless protocols, but working on an approach to connection-oriented DNS. Extra layer of protection on the IP address without modifying anything else. PINOT: network operator can still inspect and filter DNS traffic because only the source is obscured for the operator. They tried it with 350+ public DNS resolvers that support IPv6 - they were fine with requesting A records from this IPv6.
They did find asymmetry but the performance was not affected by this. They also use PINOT to talk to public NTP and for a key-based source address encryption for third party scanners - keep the source addresses from these public or third parties

Questions –

Paul Syverson: Even if the acknowledged weaker encryption is sufficient for these purposes, there is a long history of such restricted security mechanisms resulting in insecurity via function creep. Why do you think that won’t happen here? And what would be the cost of using AES instead?
A: the cost of using AES is very poor performance in the data plane, tradeoff between those Paul: have you got numbers of what the contribution of AES would be to be able to reason about the tradeoff? A: we didn’t build this, but there are calculations about AES in another paper from the group Chris Wood: What is the threat model here? Given that the network is generally considered untrusted, how could clients reasonably ensure they benefit from PINOT? A: Value-added service. Make the network trusted in this case.

Benno Overeinder: you used P4 switches, but did you consider XDP or eBPF which is easier to deploy?
A: Once the P4 network is deployed, no user involvement. Benno: could test the threat model and protocol with the other protocols.

Talk offline Britta Hale: You state that you are using static, pre-installed keys. Considering that a proxy may be compromised or by oversight request have its keys given up, how do you propose your system maintaining or achieving security over time and at scale? A: it’s not a static key. We do not record the key - just for a short-term. Generate new ones Britta: doing negotiation of keys from previous? A: just random keys

Sudheesh Singanamalla: Is there a reason why in the campus network the communication between the end-host to PINOT switch isn’t necessarily secured (exception with DNSCrypt)? Does the organization (campus/enterprise) want to know DNS requests made by users locally within the network? A: we just want to show the usefulness of this potentially, but it’s not tied to the organization model particularly

A Balanced DNS Information Protection Strategy

Scott Hollenbeck speaking for Verisign as TLD and Root operator Points out the number of TLS vulnerabilities surfaced every year. For some operators, the tradeoff to add encryption to the DNS stacks may be too risky Client information is not sent from recursive servers to authoritatives but the full FQDN is sent. We believe that Qname minimization is the best for this. It significantly reduces the risk of exposure. Maybe the risk is reduced enough versus encrypting with ADoT We do think that SLD (second level DNS servers)have a good case to do encryption with recursives.
But note that there is potential for operational impact on both parties. We encourage measurement studies to understand the impacts Other minimization techniques - NXDOMAIN/query cut, aggressive NSEC caching Minimize when possible, encrypt when needed elsewhere

Questions

Jim Reid: IETF has multiple WGs tackling this work in isolation from each other, should we take a holistic approach to the IETF and maybe stop some of the work on encryption?
A: the IETF has done a pretty good job that the various DNS WGs are sharing info. E.g. ADD and DPRIVE. IETF is traditionally challenged in operator involvement, need to get operators to this topic

Wes Hardaker: concern about things that aren’t sent on purpose, e.g. the keywords that turn into queries.
A: Verisign does publish a lot of info about the traffic we see at the root servers

Paul Hoffman: this is not an official statement from ICANN but I don’t believe that any root server or TLD operator shoud be prevented from offering better privacy with encryption. Let the operators decide themselves. In the absence of the resolvers adding the minmization features, it’s better to let the operators make their decision on this
A: no disagreement. We take this decision very seriously. If you operate a TLD that isn’t as big as COM, “knock yourself out”

Alec Muffett: what are the risks you see of not being able to see the traffic. He leans to instrumentation at the endpoints to make sure users are going to the right server etc. He doesn’t see this in the overall discussion. Is it part of the overall model A: just my opinion, I believe it is considered. Verisign blocks DOH on its corporate networks.

Armor for the back half of the camel: Why confidentiality matters for recursive DNS traffic

DKG - two humps of the camel are the Stub-to-Recursive and the Recursive-to-the-Authoritative Assumption of a network-based adversary (more or less powerful) - what we have “solved” with DOH and DOT, but of course raising other issues. Head of the camel - armor there still allows the adversary to see queries coming to recursive and leaving it. The recursive is acting as a steward of the end-user.
Timing analysis/side-analysis all remain possible and the stewardship by the resolver operator should include protecting the back half of the camel Previous talk characterized this as traffic to root, TLDs etc. Important to ack how problematic SLD are. Ex. of the New Yorker article about the Trump campaign contacts with a Russian bank - it could be done with just recursive to authoritative. DNS queries were coming from two orgs for a domain that nobody else looked up. Very revealing to see that those two were talking to each other because nobody else was looking up the domain. Problems with misconfigurations - the minimizations are risky to deploy, a SLD may be unreachable with issues of minimization A network monitor may not be able to pick out and target an individual from traffic above recursive. Who was visiting a site such as disruptj20.org? Get the ISPs from the data, then push on the ISPs by legal or extra-legal means. An resolver would do well to encrypt the back half for this. What does it mean to the authoritative if they are not offering encryption to the resolvers. The clients of an authoritative - the domain operator vs. the users of the domain. Resolver operators are stewards of both below and above. When might someone look up OpenPGP key for DKG at aclu.org. If the authoritative server doesn’t encrypt this, they are leaking info about how often DKG gets encrypted email. Lots of other types of DNS info leaks info. Authoritative servers stewardship. All of the surveillance concerns raised earlier are also the precursors to censorship. You may not be able to modify responses, if DNSSEC in use, but you can block and deny service.
Authoritative servers can consider using authoritative. It still encrypts a bunch of traffic on the network. Still need to get the rest of this figured out. The latter is next-level and we need to learn from opportunistic and get to authenticated encrypted DNS by authoritatives eventually.

Questions:

Sara says the threat landscape is well covered in this talk. We had trouble getting DoT deployed. Firefox taking control of the client was the game-changer for all of the client-2-recursive. What first mover would drive authoritatives? A: I’m not sure the analogy is super-precise here. We did see DOT adoption on Android before Firefox. People who could be first movers? Someone like Cloudflare probing toward authoritatives? Some authoritatives may decide it’s a priority and then they probers will get some benefit. Room for a bunch of folks to be first movers in this space. If there are academics researchers looking at this, create a scorecard of the results from minimized or probed/opportunistically encrypted.

Geoff Huston: do what extent to SVC queries add the potential “leakage” issue in terms of information leakage by a richer semantics of intention signalling? A: I wish I had a better metric of this. Another example is the ECH keying material. We need analysis of this topic.

Q/A / buffer time discussion

Go straight to breakouts now rather than buffer time questions

**Thanks a lot to our notetakers, Han Zhang and Austin Hounsel! **