On 11/1/2019 11:09 AM, 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?
I would think so, yes. I am also concerned with attackers "on the side". They too might try to downgrade the connections from ADOT to clear text. But yes, that should be the general concern: preventing both downgrade attacks and MITM attacks. -- Christian Huitema > > -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 [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
