On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk <[email protected]> wrote: > On Thu, Feb 06, 2020 at 12:51:21PM -0800, Eric Rescorla wrote: > > On Thu, Feb 6, 2020 at 12:44 PM Brian Dickson < > [email protected]> > > wrote: > > > > > > > > > > > On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla <[email protected]> wrote: > > > > > >> > > >> > > >> On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson < > > >> [email protected]> wrote: > > >> > > >>> Top-top-top reply: > > >>> The Internet Threat Model you are using for web client-server is > fine. > > >>> However, for DNS, that is the wrong threat model, for several > reasons. > > >>> > > >>> - The threat for DNS cache poisoning is > recursive-to-authoritative, > > >>> not client-recursive(resolver) > > >>> - The DNS path will not generally be related to the data path, and > > >>> for any parent zone, almost certainly will be totally unrelated > > >>> - DNS recursive-to-authoritative is UDP > > >>> - UDP DNS does not require that the attacker be on-path > > >>> - Compromise of DNS caches via poisoning (by potentially off-path > > >>> attackers) leading to compromise of user data is not exaggerated. > > >>> - The compromise risk is per-cache, as well as > per-authority-server > > >>> and/or per-DNS record. > > >>> > > >>> > > >> First, all of these are just consequences of the 3552 "attacker > > >> completely controls the network" threat model. > > >> > > > > > > Sorry, I'm not clear on what this statement means in this context, or > what > > > the implication of this should be inferred as being. > > > > > > Are you saying: > > > > > > - It should be assumed (per the threat model) that any/every > attacker > > > completely controls every network segment everywhere? > > > - or, that only attackers who DO control some specific network > segment > > > are a threat? > > > > > > These have vastly different implications, clearly. > > > If the first one is the case, are you conceding the precondition, that > > > attackers can poison DNS caches arbitrarily, by manipulating all DNS > > > traffic? If so, that argues in favor of DNSSEC validation by the > resolver > > > in all cases, as that is the only way the attack can be blocked. > > > > > > If the second one is the case, the bullet points you quote, contradict > > > that assertion. Specifically, that off-path attackers do not need to > > > control any network segment (let alone all network segments), to > > > successfully poison a DNS cache. This also argues in favor of DNSSEC > > > validation. > > > > > > If you mean something else, could you explain what you mean? > > > > > > > I'm saying that TLS assumes a Dolev-Yao threat model in which the > attacker > > is on-path between the client and the server and therefore can manipulate > > the traffic regardless of whether the client correctly knows the server's > > IP. > > TLS also punts the key-management story to be out of scope. > We have a lot of worked examples of the Web PKI failing (and also have lots > of people working really hard to get it to improve, which I greatly > appreciate),
I hear this argument a lot, but those examples are orders of magnitude lower than the fraction of domains which aren't even DNSSEC protected. > but given that the recursive has no way of knowing what the > DNS client is planning to do (and that some ~20% of web traffic does not > use TLS), it's hard for me to argue that this document is making the wrong > recommendation about DNSSEC validation. > The question at hand is not about whether it ought to recommend DNSSEC validation but rather whether the text around that, which implies that failure to do so has a high risk of sending your sensitive *web* traffic to the attacker, is accurate given the high fraction of Web traffic that is protected with TLS and the likely even higher fraction of sensitive traffic that is. -Ekr > -Ben >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
