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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
