Re: [dns-privacy] Threat Model

[Brian Dickson <[e-mail]>]

On Fri, Nov 1, 2019 at 1:10 PM Eric Rescorla <[e-mail]> wrote:

> It seemed like it might be a good idea to take a step back and talk
> about threat model to see if we're all on the same page.
>
> The set of threats I am concerned with is primarily about an on-path
> active attacker who learns the query stream (i.e., the domains being
> queried) coming out of the recursive resolver. It's of course mostly
> inevitable that the attacker learns which authoritative servers are
> being queried, but I think we can all agree there's still plenty of
> information to leak here [0].
>

This is where IMHO there is a major distinction between the C2R and R2A
query streams and respective privacy metrics.

C2R traffic is always PII, since the client ID (IP address) and query are
combined (literally) in the query and answer.
(NB: the proposal for "oblivious DNS" is an interesting approach that
decouples those in such a way that the resolver itself no longer has that
PII.)

There are two related considerations:

   - Does the attacker has access to timing data (source/dest IP plus port
   number indicating that DNS is being queried), even if the C2R traffic is
   encrypted?
   - How frequently has a query previously been seen (possibly "never", to
   "only from one client", to "frequently and widely seen")?

If the attacker does not have access to the timing data, IMHO the R2A
queries expose no PII, since the query data cannot be associated with an
originating client.
In this case, an on-path active attacker isn't actually a threat (!!).

If the attacker does have access to the timing data (or raw query data),
then the details of the second question come into play, including when and
how the resolver performs queries.

Here are possibilities that I can think of (which might not cover all
possibilities, everyone is welcome to add to this list):

   1. First query ever, never been cached. Must obtain from authority in
   response to new query.
   2. Only queried once, about to expire (TTL), can be preemptively
   obtained to keep the cache full.
   3. Queried multiple times by a single client, about to expire (TTL), can
   be preemptively obtained to keep the cache full.
   4. Only queried once, expired. Must obtain from authority in response to
   new query.
   5. Queried multiple times by a single client, expired. Must be obtained
   from authority in response to new query.
   6. Queried multiple times by multiple clients, about to expire (TTL),
   can be preemptively obtained to keep cache full.
   7. Queried multiple times by multiple clients, expired. Must be obtained
   from authority in response to new query.

Case #1 is obviously a rather unique case. It will always leak information.
The other 6 cases are pairs with the same semantic on the three cases that
differ only in numbers of queries and numbers of clients.
The following apply to all 3 of those pairs:
If the cache entry is allowed to expire, the next query would necessarily
leak information, as it becomes effectively a degenerate version of case #1.
If the cache entry is not allowed to expire (by preemptively doing a query
to keep the cache fresh), there might not be an association between the
query traffic (C2R) and the cache refresh traffic (R2A).
I.e. there might not be any information leak.

I believe it is the case that:

   1. If no cache entry exists and the R2A query is encrypted, there is no
   leakage. (Required for case #1, or TTL expiry every occurs).
   2. If a particular cache entry that has not been sent in the clear
   previously, and is refreshed before TTL expires, no information leak
   occurs, and it can continue to be treated as if it has never been sent in
   the clear.
   3. Only if a query has never been seen, or the TTL expires, AND the next
   query resulting in R2A is sent in the clear, does information leak.

If this strategy is used, this creates an interesting side effect.
On a busy enough resolver, the regular cache refresh traffic may be
significant enough to negatively impact timing attacks against encrypted
C2R traffic in determing IP/QNAME matches, even if port 853 is blocked and
all traffic is on port 53.


>
> In the current DNS, such an attacker can of course just perform a
> passive attack by listening to the DNS query traffic. It's possible to
> straightforwardly exclude this attack by opportunistically attempting
> DoT [1] to the authoritative. However, an active attacker can mount a
> downgrade attack on the negotiation, forcing you back to
> cleartext. So, unless you have a secure way of:
>
> (1) knowing the expected name of the authoritative for a given query
>     and that it supports DoT
> (2) verifying that the server you are connecting to actually has
>     that name
>
> Then the attacker can just mount a MITM attack on your connections and
> collect this data by proxying the traffic to the true authoritative.
>

This MITM attack method would work, and should be protected against, in
response to downgrade attacks against traffic that would otherwise leak
information.

This risk needs to be given context, specifically where are the client, the
recursive, and authoritative, and whether an attacker is able to block port
853 to cause the downgrade?
The current passive attack does not require the attacker to expose her
existence, while port blocking reveals the existence (if not the identity)
of the attacker.

Clearly there are places where such attackers are well known and
unavoidable.
The scenarios to consider include when the R2A connection is not in such an
environment, but the C2R is, and when the R2A is in such an environment but
the C2R is not, and when both connections are (even if any one of the hosts
is not in that environment).



>
> Do people agree with this assessment of the situation? Is this form
> of attack something they agree should be in scope?
>

Modulo the nuances enumerated above, I think it is necessary to analyze the
attacks to determine requirements, and to evaluate the design(s) being
proposed to validate their ability to resist the attacks (as well as
expected costs).

Brian


>
> -Ekr
>
> [0] There are of course also integrity issues here, but (1) those
> are addressed by DNSSEC and (2) if you solved the active attack
> problem, that would provide some measure of integrity for the data.
>
> [1] Or any secure transport such as DoH, DoQ, tcpcrypt, etc.
> but given the focus of this group, I'll just say DoT.
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>