Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 06, 2020 at 12:51:21PM -0800, Eric Rescorla wrote:
> On Thu, Feb 6, 2020 at 12:44 PM Brian Dickson <[e-mail]>
> wrote:
> 
> >
> >
> > On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla <[e-mail]> wrote:
> >
> >>
> >>
> >> On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson <
> >> [e-mail]> 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), 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.

-Ben