On Thu, Feb 6, 2020 at 12:58 PM Adam Roach <[email protected]> wrote: > 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? >
Sure, that's easy. WebPKI is valuable, for web traffic. Its strength is highly dependent on ensuring the client is connecting to the correct server, i.e. that DNS is not altered. WebPKI is potentially able to be made much stronger by the addition of DANE TLSA records, so that the specific choice of CA can be securely verified (preventing the malicious issuance of competing certs). WebPKI is also made much stronger by DANE TLSA, in that unpublishing a TLSA record is more reliable for asserting the invalidity of a certificate than OCSP or CRL methodologies. The latter, as I understand it, fail "unsafe", where failure to contact the CRL or OCSP server does not block the web connection. If web browsers implemented TLSA validation and failed "safe", the impact of blocking DNS traffic for a domain would be the same, whether for blocking the TLSA record or the A/AAAA records - it would be a denial of service, but would also be mitigated by the presence of DNS caching. I'm highly in favor of WebPKI, and also in favor of improving the protections against some fundamental weaknesses that currently exist, by using already-defined IETF specifications (DANE). In fact, I'll be an internal advocate for publishing TLSA records for CA certs for customer TLS certs (type 0 TLSA records) once we have ubiquitous DNSSEC signing. (TLSA requires DNSSEC). In other words, I advocate WebPKI + DNSSEC + TLSA, and that is the exact opposite of WebPKI being worthless or nearly worthless. I'm also an advocate of RPKI (BGP resource pki to prevent route hijacking) and RPKI ROA validation, and BGP route-leak-detection-mitigation (I'm a co-author of that in the GROW working group). Brian > > /a > > On 2/6/20 14:44, Brian Dickson 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? > > > >> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>>> >>>> >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
