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

[Tommy Pauly <[e-mail]>]

> On Mar 12, 2021, at 11:18 AM, Paul Vixie <[e-mail]> wrote:
> 
> On Fri, Mar 12, 2021 at 11:00:11AM -0800, Tommy Pauly wrote:
>>> This is clearly a policy prescription, and is out of scope.  ...
>> 
>> Agreed. I think the main issue is that this ends up being an "evil bit".
>> There's no reason for a client to trust or respect this value, unless they
>> already have a strong MDM-style relationship, in which case this wouldn't
>> be needed.
> 
> i understand why someone working at microsoft or google would confidently
> assert the above positions, but the rest of the world doesn't work that way.
> 
> it's not an evil bit. it's a policy expression. as someone who operates and
> secures managed private networks, the ability to detect noncompliance is
> vital to _everything else_. therefore the state of compliance must be easily
> expressed. there are also some non-security benefits, such as configuration
> management to tell BYOD (who won't be participating in MDM) how to get reliable
> service. but it's the work flows leading to anomaly detection which provide
> the strongest motive for being able to express this policy.

I think this leans towards a bit that says that the network will try to block DNS to other entities. That might make sense, but it’s different from a bit that says “please voluntarily disable your device security policy”.
> 
>> I am in favor of letting the network prove authority for private domains, or
>> even present an identity for itself as the network operator. It's up to the
>> client to use those or ignore those.
> 
> a mobile device on a public network probably needs that kind of signaling. any
> device on a managed private network probably needs different signaling. can we
> come up with a unified proposal that serves both situations?
> 
>> The one thing the network could do that might be useful is provide a flag
>> that it will be actively hostile to any DNS traffic it detects that does not
>> go to itself, with some reason text. The (minimal) value there is to allow a
>> client to present a reason for things being broken if the user of the client
>> device also has a strict policy to not trust this network.
> 
> 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.

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.

I think the reason that any of this discovery or signaling matters is when you have devices joining networks where the devices and the networks are owned and managed by different entities. Yes, that’s sometimes a mobile phone user in a cafe; but it could also be someone visiting your house, or when you first put a new device onto an enterprise network before settings things up.

The point is, 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

Tommy

> 
> -- 
> Paul Vixie
> 
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add