Hi everyone, my name is Basi and I'll present our
work on institutional privacy risks in
sharing DNS data.
This is a joint work with my PhD advisors,
Professor Aleksandr Korolova and Professor
John Heidemann.
Almost all online activities such as accessing a
website or sending an email start with a
DNS query.
Therefore, DNS queries can say a lot about end
users' online activities and this privacy
risk has been well understood and studied in the
past.
In our work, we introduce a new aspect of DNS
privacy which we call institutional privacy,
which is concerned with the behavior of an
institution's traffic as a whole.
In contrast to individual privacy, this has not
been closely studied before, but it's
important to look at because an institution's
internal activities such as sending or receiving
an email can leave a digital trail in the DNS
ecosystem.
Based on this motivation, our contributions in
this work are first to define institutional
privacy as a new privacy risk in DNS.
And within this threat model that we define, we
give a methodology for finding institutional
privacy leaks and then we apply this methodology
to real-world data that's anonymized and show
the privacy risks and also demonstrate that the
anonymization method that's used is not
sufficient to prevent institutional leaks.
To start off with how we define institutional
privacy, we broadly define it as confidentiality
of digital footprints of an institution's
internal activities.
Examples of specific activities that may leak
information through DNS include, for example,
two institutions sending or receiving an email
between each other which may reveal a
relationship
between them that's not known publicly.
Or another activity is an employee of a company
accessing a privacy-sensitive website that's
considered embarrassing from the company's peer
perspective, such as an illegal or an
adult website and accessing such websites while
on the company's network.
For our threat model, we consider an adversary
that's at the authoritative server and has
either access to the server logs or the traffic
between the recursive and authoritative server.
And the goal of the adversary is to associate the
source IP and the domain name in the query
to the corresponding institution.
The adversary targets an institution that meets
two kinds of conditions.
The first one is the institution must run its own
recursive resolver.
This would let the adversary use the resolver's
IP address to uniquely identify the DNS traffic
of the institution.
And the second condition is the institution must
route traffic from its own autonomous
system.
And this would let the adversary map the resolver's
IP address to the corresponding autonomous
system that's owned by the institution.
Many institutions' adversaries fit our threat
model.
In our study, we studied queries from six
institutions that meet the conditions that
I just listed and also represent a diverse set of
sectors such as largest MP500 companies,
government institutions, University of Southern
California schools, and so on.
And when we pick these companies, we exclude
institutions that have apparent deniability
such as ISPs or hosting service providers because
queries from these companies might
be coming from their customers and not from their
employees.
And examples of potential real-world adversaries
in our threat model include DNS service providers,
and also researchers that have access to data
that's shared by the service providers for
research purposes, and also government-level
actors that have the means to eavesdrop on
DNS traffic.
In this talk for our methodology, I focus on how
we associate queries with an institution
and how we find queries related to email, but
there is more in the paper.
As I mentioned earlier, the goal of the adversary
is to associate the source IP and the domain
name with an institution.
So, for the source IP, we use public IP to AS
number mapping data to map the source IP
to the institution that owns the AS.
And this works even if partial preserving anonymization
method is used.
And second, for the domain name, we use a public
Whois data to map the domain name to
the institution that owns the domain.
Here we assume the domain is in full and that QNAME
minimization is not being used.
Once we identify queries related to an
institution, we filter and find queries that are
related
to email exchange.
The first one is MX queries, which are made by
mail servers before sending an email.
And in this case, the source IP of the query
identifies the sender of the email and the
domain name in the query identifies the intended
recipient.
And the second type of query we look at is DNSBL
queries, which are made by anti-spam
services upon receiving an email.
In this case, the source IP identifies the
recipient of the email and the IP address
that's embedded within the domain name identifies
the sender of the email.
We apply this methodology to one week of B-Root
data and we also reproduce our results on
a second week.
This data set is anonymized using a prefix
preserving method.
The bottom eight bits are anonymized.
And we run this experiment with IRB approval and
with the permission of the data owners.
And the research questions that we looked at are
first, how common are sensitive email
related queries?
And then within these queries, are we able to
find specific relationships between institutions
that's not otherwise publicly known?
In the paper, we also look at how common are
queries to sensitive sites, which I won't
cover in this talk.
So first we looked at how common are MX and DNSBL
queries in the data set that we looked
at.
This plot shows the x-axis is the seven days of
data that we looked at and the y-axis is
the number of queries in millions.
And we can see that several millions of DNSBL and
MX queries are made each day, which can
be a significant source of leakage of email
related traffic.
And within this millions of queries, we can go
further and ask, are we able to narrow
down and look for specific relationships between
institutions?
And in this slide, the plot on the left shows a
breakdown of those MX queries by the different
sectors of companies that we studied and the plot
on the right narrows down even further
and looks at queries made to specific
institutions such as Palantir.
And we mentioned some examples of specific
relationships that we find.
For example, US Department of Justice IP address
requesting MX record of Palantir.com, which
is in line with the known fact that Palantir
works with government agencies.
And another example is a school board in
Jefferson Parish requesting MX record of ICE,
which
is also in line with the known fact that this
parish is known to work with ICE in their
deportation efforts.
We show these examples just based on one week of
data, but we expect a more dedicated adversary
that can look at a longer duration of traffic to
find even more institutional privacy violations.
So based on these results, our recommendations
are for institutions to deploy query name
minimization wherever possible.
So we recommend an even faster adoption of this
mechanism.
Another option is to use a mechanism called local
routes, which caches the route zone
locally so that the recursive resolver does not
have to make queries to the route server.
And for service providers, our recommendations
are first we have shown that host-only anonymization
is not sufficient for protecting institutional
privacy.
So we recommend service providers to put legal
constraints when sharing DNS data and for
the case of wider sharing where that's not
possible, that they look into more rigorous
privacy preserving data sharing approaches.
In this work, we have shown that DNS queries may
leak significant institutional information
that's otherwise not publicly known.
Therefore, we recommend institutions deploy query
name minimization wherever possible
and that service providers evaluate institutional
privacy risks when sharing DNS data for research
purposes.
With that, I conclude my talk.
Thank you for listening.
Our paper and data can be found at the link shown
on the slide.