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

[Adam Roach <[e-mail]>]

This is really getting off into the weeds.

Brian -- a lot of your assertions seem to be predicated on some 
underlying assumption that WebPKI is worthless or nearly worthless. Can 
you clarify whether that's your stance?

/a

On 2/6/20 14:44, Brian Dickson wrote:
>
>
> On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson
>     <[e-mail]
>     <mailto:[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?
>
>
>     Second, the text in question is about the effect of attacks on DNS
>     on the Web "Users may be directed to bogus IP addresses for e.g.
>     websites where they might reveal personal information to attackers."
>
>
> Correct, and I don't see anything you say here refuting the concern 
> over DNS cache poisoning attacks, which result in bogus IP addresses 
> directing users to malicious servers, etc.
>
> If users are sent to the wrong IP address, this substantially weakens 
> the argument that WebPKI is sufficient protection.
>
> Why are CLR and/or OCSP needed, if not to respond to compromised 
> certificates (meaning leaked private keys)?
>
> Am I missing something about WebPKI, beyond the private key proof of 
> possession model?
> (Everything else about WebPKI is about validating the requestor's 
> authority and identity, but that is all orthogonal to key control.)
>
> A web server using a compromised key is only ever going to be visible 
> to a (potential) victim, and never to third parties including the 
> legitimate certificate holder, except incidentally to operation of the 
> rogue server.
>
> Brian
>
>     -Ekr
>
>
>         I haven't written up the details of the more effective cache
>         poisoning attacks, but have been sharing summary information
>         for several years now.
>         (The underlying issue is IP fragmentation of UDP packets. This
>         is one of the contributing factors that the DNS Flag Day for
>         2020 will include recommendations/requirements to not fragment.)
>
>         I'd be willing to write up those more effective attacks,
>         including a PoC, but that won't likely happen for a few months.
>
>         Brian
>
>         On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             Thanks. I am just looking at this text, and I think it's
>             inappropriate. To recap something I seem to be saying a
>             lot lately, the Internet Threat Model assumes a
>             Dolev-Yao-style attacker who controls the network between
>             the client and the server. TLS is designed to be secure in
>             this environment, and while the WebPKi is imperfect,
>             suggesting that compromise of local DNS lookups leads to
>             compromise of user data seems exaggerated, at least in the
>             case of Web traffic.
>
>             -Ekr
>
>
>             On Thu, Feb 6, 2020 at 10:22 AM Adam Roach
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>                 Top-posting because I agree with the facts as you
>                 present them. I just reach a different conclusion
>                 based on these facts. To be clear, I think a
>                 belt-and-suspenders approach is generally preferable.
>                 I am merely suggesting that the "must" statement I
>                 cite may be stronger than is actually advisable given
>                 that such an approach is merely a small increment of
>                 security for protocols that are otherwise secured
>                 (e.g., HTTP, which is the example the document
>                 chooses), rather than the sole defense, as may be the
>                 case with other protocols.
>
>                 My top-line suggestion here is to choose a different
>                 example than HTTP.
>
>                 Secondary to that is a suggestion that the "must"
>                 statement really only makes sense when it is a sole
>                 counter-measure, and that a softer recommendation
>                 ("should") makes more sense otherwise.
>
>                 These are non-blocking comments, so I'm going to
>                 reiterate that the WG can ignore them -- I just wanted
>                 to make sure they were considered. It would be nice to
>                 hear from other folks on the topic as well.
>
>                 /a
>
>                 On 2/6/20 11:57, Brian Dickson wrote:
>>
>>
>>                 On Thu, Feb 6, 2020 at 9:31 AM Adam Roach
>>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>                     On 2/6/20 09:08, Adam Roach wrote:
>>                     >
>>                     > For the specific example chosen, it's been made
>>                     pretty clear over the
>>                     > years that at least the clients for the
>>                     specific service you cite have
>>                     > no interest in incurring this additional cost.
>>                     If that's the working
>>                     > group consensus, then I have no interest in
>>                     over-riding it. But
>>                     > ignoring operational realities seems kind of
>>                     ivory tower-ish, which
>>                     > feels like the kind of thing that undermines
>>                     the general credibility
>>                     > of the rest of the document.
>>                     >
>>
>>
>>                 Could you please be more specific?
>>
>>                 When you say "for the specific service", do you mean
>>                 DNSSEC?
>>
>>                 And do you mean the signing of DNS zones using
>>                 DNSSEC, when you refer to clients of that service?
>>
>>                 Perhaps you missed my microphone comments at the last
>>                 IETF?
>>
>>                 Specifically that GoDaddy will be turning on DNSSEC
>>                 for the vast majority of its DNS hosting customers?
>>
>>                 This represents about 40% of the DNS zones on the
>>                 Internet.
>>                 (The exact time frame is not set in stone, but we
>>                 expect this to be done in the first half of 2020.)
>>
>>                 Given that this significantly alters the calculus, I
>>                 don't think that is a good enough reason to object in
>>                 and of itself anymore.
>>
>>                 The other aspect of this is the asymmetry involved in
>>                 the defenses against impersonation:
>>
>>                   * The choice to sign a DNS zone is under control of
>>                     the zone owner
>>                   * The choice to deploy RPKI on routes (to protect
>>                     against BGP hijacking) is under control of the IP
>>                     prefix holder
>>                   * Both methods rely on third parties to cooperate
>>                     to achieve the protections offered
>>                   * RPKI routing filters are now widely deployed, and
>>                     RPKI registrations are substantial
>>                   * The remaining issue is DNSSEC validation; many
>>                     (most?) of the public recursive operators do this
>>                     already
>>
>>                 The logic should be, defend against all feasible
>>                 attacks, rather than justifying the non-defense in
>>                 one area (DNSSEC for DNS) based on the assertion that
>>                 another area is not being defended (RPKI for BGP).
>>
>>                 Brian
>>
>>
>>                     I realize that my editing made one of the pronoun
>>                     antecedents here go
>>                     away. The second sentence should have said
>>                     something more like "If
>>                     keeping the current text is the working group
>>                     consensus..."
>>
>>                     /a
>>
>
>                 _______________________________________________
>                 dns-privacy mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/dns-privacy
>