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

[Tommy Jensen <[e-mail]>]

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

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 <[e-mail]> On Behalf Of Eric Rescorla
Sent: Thursday, July 1, 2021 3:18 PM
To: ADD Mailing list <[e-mail]>
Subject: [EXTERNAL] [Add] Private IPs, DDR, and PR#11

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.