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

[Eric Rescorla <[e-mail]>]

On Sat, Nov 2, 2019 at 6:01 AM Paul Hoffman <[e-mail]> wrote:

> 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.
>

Generally, I would expect that a solution which addressed the active threat
model would also address the passive one.



> 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.
>

Sure. Let's say "identity"

=Ekr


> --Paul Hoffman
>