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

[Tommy Jensen <[e-mail]>]

> -----Original Message-----
> From: Add <[e-mail]> On Behalf Of Paul Vixie
> Sent: Friday, March 12, 2021 11:19 AM
> To: Tommy Pauly <tpauly=[e-mail]>
> Cc: Ben Schwartz <bemasc=[e-mail]>; ADD Mailing list
> <[e-mail]>; tirumal reddy <[e-mail]>
> Subject: [EXTERNAL] Re: [Add] New Version Notification for draft-reddy-add-
> enterprise-split-dns-01.txt
> 
> 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.

This is not about our different views on the industry (though I'll point out that our products are used by enterprises and others who wish to secure their networks as well). This is the engineering reality. Unauthenticated bits representing unverifiable properties on the wire could come from well-intentioned network administrators or attackers.

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

For an interactive UX, a captive portal can do this. In the IoT case, nothing can really do it since the non-cooperative devices you're worried about won't be listening to your signal anyway. Am I missing a pivot? I do not see how communication of policy has anything to do with detection of non-compliance.

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

Functionally, DNR will do this (a device can assume the network knows best what resolvers are customized for itself). For policy, of course, see my last comment.

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

I would like some help understanding what we need to do in the user-less scenario. As I outlined on another thread, I don't see how protocol work will affect a positive outcome. I'll revisit Glenn's last response which I do not believe I have responded to yet.

Summary, my personal dead horse: if we do want networks to be able to communicate policy to a client in a way that can be differentiated from an attacker, it should be more general than DNS and it should be not in ADD. I will happily follow proposals out of this WG if and where they are made. If there already is one, please ping me. Within ADD, we should be describing network/resolver capabilities, not their desired client behavior.

> --
> Paul Vixie
> 
> --
> Add mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
> %40microsoft.com%7C840251d2a8534bb26bd908d8e58bab65%7C72f988bf86
> f141af91ab2d7cd011db47%7C1%7C0%7C637511735366742308%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C1000&amp;sdata=3R60g8aH6TN04uIl%2BhWVG9m1E3
> xXRWli2gObMFyB7HU%3D&amp;reserved=0