Re: [dns-privacy] [Ext] Threat Model

[Paul Hoffman <[e-mail]>]

On 11/1/19 2:09 PM, Eric Rescorla 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].
> 
> 
> 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.
> 
> Do people agree with this assessment of the situation? Is this form
> of attack something they agree should be in scope?

This is one threat model, definitely. Another is passive snooping, such by someone who is watching at a point on the resolver's upstream connection to interesting authoritative servers. Another is passive snooping, such by someone who is watching at a point near interesting authoritative servers.

One small modification I would make to your mode is to change #1 from "knowing the expected name of the authoritative" to "knowing an expected identifier of the authoritative", and #2 to "...actually has that identifier". Given the current landscape of resolvers and authoritative servers, using long-lived IP addresses for identification might be better; that would need to be hashed out during protocol discussion.

--Paul Hoffman