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?
- 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
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! **