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

[Eric Rescorla <[e-mail]>]

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

>
> On Thu, Jul 1, 2021 at 6:18 PM Eric Rescorla <[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.
>

I think perhaps I missed 5.2, but I don't think it really answers my
question: what actual network environment does this correspond to? How
common is it? The rationale for the original DDR was that DHCP was somehow
special and could be trusted to deliver the IP address of the resolver, but
that's not true here.



[1]
> https://datatracker.ietf.org/doc/html/draft-ietf-add-requirements#section-5
>
> That would also help understand the effectiveness of the 5 minute
>> timeout.
>>
>>
>> Finally, assuming I've understood things correctly, reaching through
>> the CPE in this way seems like it has the potential to bypass any
>> CPE-specific filtering that the user has has installed. Suppose I have
>> some CPE that uses the ISP DNS but filters out certain names; if the
>> ISP posts a _SVCB record that directs me to their resolver, doesn't
>> that cause that filtering not to work?
>>
>
> Yes, but the CPE controls whether this upgrade occurs.  To control the DDR
> process, the CPE replies to the SVCB query (ideally advertising its own
> encrypted endpoint, but NODATA/NXDOMAIN will also work).
>

I would say rather that the CPE has the opportunity to prevent the upgrade
from occurring. However, as I understand the situation, the current CPEs
that do filtering will simply be invisible to this process.

-Ekr