Re: [dns-privacy] [Ext] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Paul Hoffman <[e-mail]>]

On Jan 9, 2020, at 7:41 PM, Eric Rescorla <[e-mail]> 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