On Fri, Jan 10, 2020 at 6:50 AM Paul Hoffman <[email protected]> wrote:
> On Jan 9, 2020, at 7:41 PM, Eric Rescorla <[email protected]> wrote: > >>>> Section 3.5.1.2 > >>>> > >>>> I admit that I don't understand the purpose of this section. > Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is > far too low level. If we were to simply assume the usual threat model > [RFC3552], then the conclusions here are obvious: if you fail to > authenticate the server, then you get the server that an attacker chooses.. > >>>> > >>>> I would remove this section in favour of improving Section 3.5.1.4, > which addresses the most pertinent question. > >>> > >>> RFC7626 included Section 2..5.3 > https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This > section is just an update of that text to improve context and remove the > phrase ’rogue server’. Since the majority of OS implementations still use > these mechanisms today it seems to still be relevant. > >>> > >>> Well, as MT says, this is just the 3552 threat model. The basic fact > is that you need a reference to a server that is (1) securely obtained and > (2) verifiable against the server itself. Absent that, you are subject to > attack by the network. > >> > >> Suggest adding a sentence at the start of the section “[RFC3552] > provides guidelines for describing Internet threat models. This section > specialises the discussion to the case of DNS resolver configuration.” > >> > >> Well, that's a start, but the problem is still that it's too low level.. > If you insist on having this section, you should lay out the implications > of the situation rather than (or at least in advance of) digging into the > details. > > > > The level is detail is entirely comparible to that in the original RFC > (much of the text is still the same). > > > > That doesn't seem like a particularly strong argument. We're revising > this document and the question is what is good now. > > > > > > > > As I said to Martin, the section focusses on the impact on the DNS > resolution path that results from the attack: diversion of traffic and > traffic capture.. Are there other implications you think should be > included? Please suggest text. > > > > I would replace the entirety of this section with: > > > > The Internet Threat model, as described in RFC 3552, assumes that the > attacker controls the network. Such an attacker can completely control any > insecure DNS resolution, both passively monitoring the queries and > responses and substituting their own responses. Even if encrypted DNS such > as DoH or DoT is used, unless the client has been configured in a secure > way with the server identity, an active attacker can impersonate the > server. This implies that opportunistic modes of DoH/DoT as well as modes > where the client learns of the DoH/DoT server via in-network mechanisms > such as DHCP are vulnerable to attack. In addition, if the client is > compromised, the attacker can replace the DNS configuration with one of its > own choosing. > > Given that this topic is one where there is rampant confusion, I think > brevity and clarity are best for this document. I believe Ekr's words cover > exactly what is needed here, and agree that the rest of the section should > be eliminated. > > I aslo agree with earlier comments that this document referring to > draft-arkko-arch-infrastructure-centralisation is a bad idea. We have no > idea what that document will end up saying when published as an RFC. > Or whether it will be published as an RFC at all. -Ekr > --Paul Hoffman-- > last-call mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/last-call >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
