On Sat, Nov 2, 2019 at 6:01 AM Paul Hoffman <[email protected]> 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 >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
