On Jan 9, 2020, at 7:41 PM, Eric Rescorla <e...@rtfm.com> 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. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
