Re: [Add] Private IPs, DDR, and PR#11

[Andrew Campling <[e-mail]>]

On Wed, Jul 8, 2021 at 04:11 Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

> On Wed, Jul 7, 2021 at 8:01 AM Ben Schwartz <[e-mail]<mailto:[e-mail]>> wrote:

On Thu, Jul 1, 2021 at 6:18 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

Can we get this documented before we start designing mechanisms?

I'm not sure what you mean.  Section 5 of the requirements draft [1] says

    +-------------+---------------------------------------------------+
    | R4.1        | If the local network resolver is a forwarder that |
    |             | does not offer encrypted DNS service, an upstream |
    |             | encrypted resolver SHOULD be retrievable via      |
    |             | queries sent to that forwarder.                   |
    +-------------+---------------------------------------------------+
    | R4.2        | Achieving requirement 4.1 SHOULD NOT require any  |
    |             | changes to DNS forwarders hosted on non-          |
    |             | upgradable legacy network devices.                |
    +-------------+---------------------------------------------------+
    | R5.1        | Discovery MUST NOT worsen a client's security or  |
    |             | privacy posture.                                  |
    +-------------+---------------------------------------------------+
    | R5.2        | Threat modelling MUST assume that there is a      |
    |             | passive eavesdropping attacker on the local       |
    |             | network.                                          |
    +-------------+---------------------------------------------------+
    | R5.3        | Threat modelling MUST assume that an attacker can |
    |             | actively attack from outside the local network.   |
    +-------------+---------------------------------------------------+
    | R5.4        | Attackers MUST NOT be able to redirect encrypted  |
    |             | DNS traffic to themselves when they would not     |
    |             | otherwise handle DNS traffic.                     |
    +-------------+---------------------------------------------------+

I think these requirements (except perhaps R5.3) represent the goal of PR #11.

Just reflecting on R5.1, if a user has currently opted for an unencrypted resolver with filtering of malicious content, moving them to an encrypted resolver with unfiltered content would present an interesting case given the increased exposure that this implies.  I know that some are not fans of DNS filtering, however it is used widely (possibly not in the USA?).  Taking into account the additional protection that such filtering offers when determining appropriate options via discovery seems to be a reasonable expectation from a user perspective, particularly a non-expert user.

Andrew