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

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Jul 2021 15:17:33 -0700

I've been spending some time thinking about PR#11 and trying
to figure out the threat model where it brings value. This
message is an attempt to get to a better understanding. As
should be clear, I'm a little confused, so if people want
to tell me why I'm wrong, that would be helpful.

First, let's start with what I take to be the network topology:

                   ISP Resolver
                    192.0.2.1
                        |
                        | <- ISP Network
                        |
                    192.0.2.100
                   CPE/DNS Proxy
                     10.0.0.1
                        |
                        | <- Home network
                        |
                     10.0.0.100
                    Users device

We have the ISP's resolver with a public address of 192.0.2.1.  The
user has some sort of CPE with an external address of 192.0.2.100 and
an internal address of 10.0.0.1. The user's device has an IP of
10.0.0.100. When the user's device does DHCP, it gets the address
10.0.0.1 for its resolver, presumably because the CPE intends to proxy
or cache DNS, otherwise it could just serve the ISP's resolver address
(192.0.2.1) in DHCP.

The general assumption for the DDR threat model so far is that:

1. The user's device gets the address of its resolver securely
(presumably because DHCP is secure in some way). If that's not true,
then I think we can agree that DDR does not provide much additional
security benefit because the attacker can just substitute their own
resolver [0].

2. Either the home network or the ISP network is insecure, otherwise
you don't need DoX.

OPPORTUNISTIC MODE
So, first, its not entirely clear to me what the Opportunistic mode of
S 4.2 provides. In this scenario, presumably the client will be doing
TLS to the CPE (because otherwise the IP address would be the
resolver's public address), which means that we are concerned with the
attacker controlling the home network. So, in this scenario, we are
only getting value if you have a network in which:

1. The attacker can *see* traffic not destined for their IP address
   (otherwise there's not much point in encrypting).
2. The attacker cannot forge traffic from another IP address
   (otherwise they can just impersonate the CPE because there
   is no certificate).

Are there an appreciable number of networks with these properties? If
so, can we write down where that happens and put it in Security
Considerations? If not, we should consider removing this mode.

PR #11
The idea with PR#11 seems to be to bootstrap up from a local IP
address issued via DHCP to some other address. PR#11 doesn't do that
great a job of describing the setting, but I'm assuming the scenario
is that we want to start from a situation in which we have a CPE-based
proxy and move to a situation in which the user's device talks directly
to the ISP resolver. Otherwise, presumably, we could just make do
with the mode in S 4.2. Is this right or am I missing something?
And the reason we're not just vending the ISP's resolver directly
via DHCP is that the CPE isn't upgradeable or potentially under
the user's control and not the network's?

So, first, what threat model are we concerned with:

1. If it's control of the home network, then why can't the attacker
   block the _SVCB record between the user and the CPE stopping
   them from upgrading?

2. If it's control of the link to the ISP, then why can't the
   attacker just block the resolution of the _SCVB record between
   the CPE and the ISP's resolver? Maybe the CPE is using DoX,
   but we're trying to protect against *future* compromise
   of the user's network?

Can we get this documented before we start designing mechanisms?
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?

-Ekr

[0] Modulo cdisco-style steering where the address is matched up
against a trusted list.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 14:42:19 -0400

> First, let's start with what I take to be the network topology:

I think that the implicit placing of the CPE IP + the ISP Resolver on the
same subnet suggests more security than is really the case.
I can forgive the numbering and imagine that the ISP Resolver is really on
some other subnet, some distance away.  But, therein lies the issue.

The ISP Network hop could involve a significant stretch across a Metro network.
(in most Canadian provinces, the DSL connection travels across province to
some DC, often on a wide variety of third party fibers, which are trivially
subject to Mallory-in-the-Rough [offpath] eavesdropping)
This use case is even part of the APN (BOF) use case situation.

    > 2. Either the home network or the ISP network is insecure, otherwise

So the word "insecure" is ambiguous here.
It could mean:
Malory-in-The-Middle, Malory-on-the-side, malory-in-the-rough

DoX defends against many of these things.

We agreed in add that we have to assume that the home network's DHCP is
secure (via DHCP/RA-Guard filters on the home router's wifi hairpin).
I'm unclear if we have real ARP-spoofing guards.

    > (otherwise there's not much point in encrypting).

ARP-spoofing of ".1" is common and in some cases, even considered a feature
that enables a VPN.

    > (otherwise they can just impersonate the CPE because there

DHCP Guard makes this harder.

    > Considerations? If not, we should consider removing this mode.

I mostly agree.

    > block the _SVCB record between the user and the CPE stopping

Because that depends upon the kind of attack you are assuming.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 7 Jul 2021 11:01:25 -0400

On Thu, Jul 1, 2021 at 6:18 PM Eric Rescorla <[email-masked]> wrote:
...

> to the ISP resolver.

Yes, that's the key motivating use case.

> Otherwise, presumably, we could just make do

Yes, or
- because the CPE proxy performs caching for Do53 but recommends E2E
encryption for clients that can use it
- because the CPE needs to generate DHCP/RA before it knows the ISP
resolver's IP address
- maybe other reasons

>    but we're trying to protect against *future* compromise

Neither: the threat that PR #11 adds to the scope is a passive adversary on
either link.  An active adversary can always win, as you note.

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.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-add-requirements#section-5

> 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).  Mozilla's "canary
domain" experiment seems to have proven that this arrangement works well in
practice, to support this kind of network.

Additionally, PR #11 says:

> Some networks contain legacy forwarders whose behavior cannot be updated.
> For compatibility with these networks, clients MAY impose additional
> conditions
> on discovery from a Private IP, such as requiring that the Encrypted
> Resolver
> is on the same IP address as the Unencrypted Resolver.

In other words, neither endpoint is obliged to participate in this scheme.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 7 Jul 2021 16:45:59 +0000

Just my 0.02: I would support removing this whether in PR#11 or DDR as it stands. The reason we added this “same IP is allowed without verification” mechanism was in response to WG feedback that expecting ecosystem members to accomplish this on our own was unreasonable (the authors originally said “we leave that to DoT knocking which is already suggested in RFC7858”).

I see Michael already commented on this; it would be useful to hear more WG commentary on this point. I was under the impression that there is some subset of network operators who found that useful. If not, we should revisit.

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Eric Rescorla
Sent: Thursday, July 1, 2021 3:18 PM
To: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] [Add] Private IPs, DDR, and PR#11

                   ISP Resolver
                    192.0.2.1
                        |
                        | <- ISP Network
                        |
                    192.0.2.100
                   CPE/DNS Proxy
                     10.0.0.1
                        |
                        | <- Home network
                        |
                     10.0.0.100
                    Users device

OPPORTUNISTIC MODE

PR #11

-Ekr

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Wed, 7 Jul 2021 21:02:54 +0000

This is an important discussion and I’m a little worried that it’s not getting enough eyes on it at the moment  – which is why there isn’t a lot of traffic discussing it – very possibly due to it being a popular vacation time in the US and elsewhere for summer and people busily on other drafts/things.   So making a big decision on list traffic alone at the moment might be a bit rushed.

I do recall that previously the WG had discussed the scenario and it was important to an number of people and we’ve already had a lot of discussion that went into building up the requirements Doc around this.

Suggestion:   Before anything gets even seriously considered for removal, we should discuss the proposition during the ADD session for IETF111, and in any post IETF111 list traffic that discussion may trivver.   Is someone(s) willing to put together a couple of slides documenting the scenario at IETF111?

-glenn as ADD co-chair

Thanks,
Tommy

                   ISP Resolver
                    192.0.2.1
                        |
                        | <- ISP Network
                        |
                    192.0.2.100
                   CPE/DNS Proxy
                     10.0.0.1
                        |
                        | <- Home network
                        |
                     10.0.0.100
                    Users device

OPPORTUNISTIC MODE

PR #11

-Ekr

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 7 Jul 2021 17:17:41 -0400

I agree that this topic is worthy of agenda time.  I would be happy to
contribute some slides, perhaps in collaboration with someone who's argued
the opposite side.

On Wed, Jul 7, 2021 at 5:03 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> This is an important discussion and I’m a little worried that it’s not
> getting enough eyes on it at the moment  – which is why there isn’t a lot
> of traffic discussing it – very possibly due to it being a popular vacation
> time in the US and elsewhere for summer and people busily on other
> drafts/things.   So making a big decision on list traffic alone at the
> moment might be a bit rushed.
>
>
>
> I do recall that previously the WG had discussed the scenario and it was
> important to an number of people and we’ve already had a lot of discussion
> that went into building up the requirements Doc around this.
>
>
>
> Suggestion:   Before anything gets even seriously considered for removal,
> we should discuss the proposition during the ADD session for IETF111, and
> in any post IETF111 list traffic that discussion may trivver.   Is
> someone(s) willing to put together a couple of slides documenting the
> scenario at IETF111?
>
>
>
>
>
> -glenn as ADD co-chair
>
>
>
> On 7/7/21, 9:46 AM, "Add on behalf of Tommy Jensen" <[email-masked]
> on behalf of Jensen.Thomas=[email-masked]> wrote:
>
>
>
> Just my 0.02: I would support removing this whether in PR#11 or DDR as it
> stands. The reason we added this “same IP is allowed without verification”
> mechanism was in response to WG feedback that expecting ecosystem members
> to accomplish this on our own was unreasonable (the authors originally said
> “we leave that to DoT knocking which is already suggested in RFC7858”).
>
>
>
> I see Michael already commented on this; it would be useful to hear more
> WG commentary on this point. I was under the impression that there is some
> subset of network operators who found that useful. If not, we should
> revisit.
>
>
>
> Thanks,
>
> Tommy
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, July 1, 2021 3:18 PM
> *To:* ADD Mailing list <[email-masked]>
> *Subject:* [EXTERNAL] [Add] Private IPs, DDR, and PR#11
>
>
>
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Jul 2021 22:20:15 +0000

As I've already stated, I think "the same IP address" provision is fairly useless in the context of home networks because the likelihood of home routers being upgraded to support DoH is low.
With that said, I also think the "threat" of passive "attackers" in the home network is highest for malware and children. The parents and other adults are probably fully aware of any security services / firewalls / parental controls they've set up and don't feel like these passive sniffing services are threats or attacks. But it's important that we protect malware and children from the evil router-based security services.
Personally, I think that making it harder and harder to detect malware is the bigger threat to end users. But I suspect I'm in the minority here.

Thx,
Barbara

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Wednesday, July 07, 2021 4:18 PM
To: Deen, Glenn (NBCUniversal) <[email-masked]>
Cc: [email-masked]; [email-masked]; Tommy Jensen <Jensen.Thomas=[email-masked]>
Subject: Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11

I agree that this topic is worthy of agenda time.  I would be happy to contribute some slides, perhaps in collaboration with someone who's argued the opposite side.

On Wed, Jul 7, 2021 at 5:03 PM Deen, Glenn (NBCUniversal) <[email-masked]<mailto:[email-masked]>> wrote:
This is an important discussion and I'm a little worried that it's not getting enough eyes on it at the moment  - which is why there isn't a lot of traffic discussing it - very possibly due to it being a popular vacation time in the US and elsewhere for summer and people busily on other drafts/things.   So making a big decision on list traffic alone at the moment might be a bit rushed.

I do recall that previously the WG had discussed the scenario and it was important to an number of people and we've already had a lot of discussion that went into building up the requirements Doc around this.

-glenn as ADD co-chair

Just my 0.02: I would support removing this whether in PR#11 or DDR as it stands. The reason we added this "same IP is allowed without verification" mechanism was in response to WG feedback that expecting ecosystem members to accomplish this on our own was unreasonable (the authors originally said "we leave that to DoT knocking which is already suggested in RFC7858").

Thanks,
Tommy

From: Add <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Thursday, July 1, 2021 3:18 PM
To: ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] [Add] Private IPs, DDR, and PR#11

                   ISP Resolver
                    192.0.2.1
                        |
                        | <- ISP Network
                        |
                    192.0.2.100
                   CPE/DNS Proxy
                     10.0.0.1
                        |
                        | <- Home network
                        |
                     10.0.0.100
                    Users device

OPPORTUNISTIC MODE

PR #11

-Ekr

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Jul 2021 20:11:10 -0700

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

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]
> 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

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Jul 2021 08:24:35 -0400

> special and could be trusted to deliver the IP address of the resolver, but

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.

[1]
>> 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

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.

---

From: Andrew Campling <[email-masked]>
Date: Thu, 8 Jul 2021 12:48:08 +0000

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

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

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jul 2021 06:09:42 -0700

> 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

>> 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.
>>
>
> (be it use-application-dns.net or _dns.resolver.arpa),
> avoiding disruptions in practice.
> --
> Add mailing list
> [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Jul 2021 11:45:55 -0400

...

> this scenario is at all common?

I would start with Room 641A [1] and RFC 7258.

Perhaps you mean that we cannot exclude the possibility of active attacks?
This is true, but I believe there is enormous value in forcing passive
attackers to become active (or desist), as this makes their presence
detectable and enables remediation.

[1] https://en.wikipedia.org/wiki/Room_641A

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 8 Jul 2021 16:17:44 +0000

Hey Ben,

I don't think this part is under contention:

> there is a passive adversary on the public link

I think this part is:

> the local network is free of adversaries

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Thursday, July 8, 2021 8:46 AM
To: Eric Rescorla <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Private IPs, DDR, and PR#11

On Thu, Jul 8, 2021 at 9:10 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jul 8, 2021 at 5:25 AM Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>> wrote:
...
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?

Perhaps you mean that we cannot exclude the possibility of active attacks?  This is true, but I believe there is enormous value in forcing passive attackers to become active (or desist), as this makes their presence detectable and enables remediation.

[1] https://en.wikipedia.org/wiki/Room_641A<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRoom_641A&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cf135fcc0a08d495797ea08d942278961%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637613559912025247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y1oZ9h19q8sXG8KQlFRgqoEQy7kyTSc1cZoAffTB2tM%3D&reserved=0>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jul 2021 09:28:45 -0700

On Thu, Jul 8, 2021 at 8:46 AM Ben Schwartz <[email-masked]> wrote:

> Perhaps you mean that we cannot exclude the possibility of active
> attacks?  This is true, but I believe there is enormous value in forcing
> passive attackers to become active (or desist), as this makes their
> presence detectable and enables remediation.
>

Fair enough. That seems like a persuasive argument.

-Ekr