Re: [Add] New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

[Paul Vixie <[e-mail]>]

Tommy Pauly wrote on 2021-03-12 15:50:
>> On Mar 12, 2021, at 11:18 AM, Paul Vixie <[e-mail]> wrote:
>> 
>> not all networks are public, and not all on-path actors are
>> authoritarian governments or surveillance capitalists, and not all
>> devices have users. i'd like to see this discussion move to a
>> broader use case that isn't smartphone centric or web-centric or
>> coffee-shop-wifi centric.
> 
> To be clear, for the private or home network case, I don’t think this
> needs to be a problem.

i hope you're right, and i'm glad we're discussing it.

> If you are using a device on a network that you control, and you want
> you network to see all of the details, great! That should be possible
> to configure for sure. Set up your devices the way you want to. In an
> enterprise, there are also many solutions for this.

there are important and common instances in which this guidance is
inapplicable, because DoH is deliberately an extreme-entropy encoding,
designed not to be subject to interference by an on-path actor such as
my firewall. therefore my tools for detecting noncompliance with policy
have been limited for me. examples of noncompliance include:

1. misconfigurations which i would once have been able to detect with
tcpdump or netflow or PF are now invisible.

2. intruders, supply chain poisoners, and malware that wish to operate
without oversight by the local network operator are free to do so.

3. IoT devices that will never be profitable from their manufacture or
sale will not require my permission to reach their motherships.

the enterprise (MDM) solution you refer to is unavailable to me at home.
i don't think a fully viral internet where data paths can be established
without the knowledge or consent of the vast majority of network
operators and one's only choice is to plug something in or not will be
seen as beneficial.

i can choose not to use or permit browsers who set their own RDNS policy
without first gaining informed consent from the humans around them --
and i have done so.

i cannot as easily choose not to have misconfigurations, intruders,
poisoned supply chains, malware, or surveillance capitalist IoT devices.
therefore i'm asking for a choice i can make, which is to express a
policy, so that anything witnessed to not follow that policy
("detected") can be hunted (and possibly killed).

> ..., if a device has a configuration that makes it think it
> needs a certain privacy stance, and the network wants to enforce an
> incompatible policy, the best thing we can do is to make that
> conflict easy to identify and understand. The options to resolve
> depend on the situation:
> 
> - The device didn’t intend to join a network with those policies, so
> it leaves> - This is a device that is in fact owned by the same
> entity, or intended to be used in this way on this network, so it
> saves some local policy - A user is presented with a choice - …etc

i support your described model, except that "enforce an incompatible
policy" is not as obvious after RFC 8484, since such enforcement was
exactly what it desires to prevent, and this is the only salient
difference from RFC 7858 a few years earlier. "to enforce" must now be
interpreted as "detect, hunt, and kill". it's not just a firewall
setting any more.

vixie