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

On Thu, Jul 8, 2021 at 5:25 AM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

>
>
> On Wed, Jul 7, 2021 at 11:11 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Wed, Jul 7, 2021 at 8:01 AM Ben Schwartz <bemasc@google.com> wrote:
>>
>>>
>>> On Thu, Jul 1, 2021 at 6:18 PM Eric Rescorla <ekr@rtfm.com> 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.
>>
>
> The clearest use case is where the local network is free of adversaries,
> and there is a passive adversary on the public link.  I think this is
> likely a common scenario ... perhaps the most common scenario of all.
>

I'm just going to repeat my question here. Do you have any evidence that
this scenario is at all common?

-Ekr

> [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.
>>
>
> Perhaps, but such filtering lists generally have to be updated frequently
> as the destinations of concern change.  The Mozilla canary experiment has
> demonstrated that such CPEs are generally able to block the probe domain
> (be it use-application-dns.net or _dns.resolver.arpa),
> avoiding disruptions in practice.
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>