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

On Fri, Jan 10, 2020 at 6:50 AM Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Jan 9, 2020, at 7:41 PM, Eric Rescorla <ekr@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.
>

Or whether it will be published as an RFC at all.

-Ekr

> --Paul Hoffman--
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>