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

From: Ben Schwartz <[email-masked]>
Date: Thu, 1 Apr 2021 13:44:11 -0400

On Tue, Mar 30, 2021 at 1:39 AM tirumal reddy <[email-masked]> wrote:
...

> It is only a policy expression and definitely not a policy prescription.
>
...

> On Sat, 13 Mar 2021 at 00:30, Tommy Pauly <[email-masked]> wrote:
>
...

> 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.
>>
>
This reminds me of the Jean-Claude van Damme line [1]:
DeGraf: You're not gonna last too long.
Burke: Is that a threat?
DeGraf: No... that's a promise.

There's no meaningful distinction between an "expression" and a
"prescription".  Whether this flag represents a demand to comply or a
notice of enforcement, the effect is the same.

Defining a flag of this kind would amount to the IETF endorsing the
practice of network operators demanding access to all of their users' DNS
activity, i.e. browsing history.  That's out of scope for our working
group.  It also violates RFC 8890, "The Internet is for End Users".

[1] https://tvtropes.org/pmwiki/pmwiki.php/Main/IsThatAThreat

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 1 Apr 2021 21:51:19 +0200 (CEST)

>     Il 01/04/2021 19:44 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
>     Defining a flag of this kind would amount to the IETF endorsing the practice of network operators demanding access to all of their users' DNS activity, i.e. browsing history.  That's out of scope for our working group.  It also violates RFC 8890, "The Internet is for End Users".
> 
Why should this be against RFC 8890? In several countries, there are millions of users that actively opt into DNS-based parental controls and network security services that require them to share all their DNS activity with the operators providing them (either their ISP or a specialized company). These users indeed think that this is in their best interest; actually, in this case, it would be the disruption of these services that would violate RFC 8890.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 1 Apr 2021 16:31:02 -0400

On Thu, Apr 1, 2021 at 3:51 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Why should this be against RFC 8890? In several countries, there are
> millions of users that actively opt into DNS-based parental controls and
> network security services that require them to share all their DNS activity
> with the operators providing them (either their ISP or a specialized
> company).
>

This flag is not relevant to the case of "user opt-in".  It is quite
specifically a signal that the network prohibits the user from opting out.

> These users indeed think that this is in their best interest; actually, in
> this case, it would be the disruption of these services that would violate
> RFC 8890.
>
> --
>
> [email-masked]

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Thu, 1 Apr 2021 20:47:05 +0000

*   No hat on -

On 4/1/21, 1:31 PM, "Add on behalf of Ben Schwartz" <[email-masked]<mailto:[email-masked]> on behalf of bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

On Thu, Apr 1, 2021 at 3:51 PM Vittorio Bertola <vittorio.bertola=[email-masked]<mailto:[email-masked]>> wrote:

Il 01/04/2021 19:44 Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>> ha scritto:

Defining a flag of this kind would amount to the IETF endorsing the practice of network operators demanding access to all of their users' DNS activity, i.e. browsing history.  That's out of scope for our working group.  It also violates RFC 8890, "The Internet is for End Users".
Why should this be against RFC 8890? In several countries, there are millions of users that actively opt into DNS-based parental controls and network security services that require them to share all their DNS activity with the operators providing them (either their ISP or a specialized company).

This flag is not relevant to the case of "user opt-in".  It is quite specifically a signal that the network prohibits the user from opting out.

If the network is going to prevent user opt-out it’s fully capable doing that regardless of the flag. However if it existed, this flag would permit the network to inform user to be aware of what is going on.

So the flag could actually be seen as helping RFC 8890 as it provides information that the user can use in making their choice to use to use the particular network.

-glenn

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 1 Apr 2021 22:48:13 +0200 (CEST)

>     Il 01/04/2021 22:31 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
>     On Thu, Apr 1, 2021 at 3:51 PM Vittorio Bertola <vittorio.bertola=[email-masked] mailto:[email-masked] > wrote:
> 
>         > > 
> >             > > >             Il 01/04/2021 19:44 Ben Schwartz <bemasc=[email-masked] mailto:[email-masked] > ha scritto:
> > > 
No, it is a signal that the network prohibits *the client* from opting out (or, more correctly, politely asks the client not to do so, since it cannot be forced). There is no certainty that the user was involved by the client in that opt-out decision, and the network could actually be producing that signal on behalf of the user, if the user has opted into the network operator's DNS-based monitoring and security services. Or, as another example, there are cases in which public authorities representing the collectivity of the users ask or require the national network operators to perform DNS-based filtering to protect the users from various threats - this is also "for the end users". Clients that really care about their users should want to receive that signal so that they can act accordingly.

--

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 1 Apr 2021 17:39:10 -0400

On Thu, Apr 1, 2021 at 4:47 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> If the network is going to prevent user opt-out it’s fully capable doing
> that regardless of the flag. However if it existed, this flag would permit
> the network to inform user to be aware of what is going on.
>

The network can already do this via free text in a human-readable captive
portal page.

So the flag could actually be seen as helping RFC 8890 as it provides
> information that the user can use in making their choice to use to use the
> particular network.
>

Arguments on the basis of RFC 8890 are not likely to be productive: I
mention it mostly to emphasize that we are unlikely to reach consensus to
adopt this sort of mechanism.

However, on this particular point, I think it's unrealistic to expect that
most users have a meaningful choice of which network to use.  Users largely
have no choice but to submit to whatever restrictions the network demands,
so we should be very careful about what kinds of demands we endorse.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 1 Apr 2021 22:02:53 +0000

> The network can already do this via free text in a human-readable captive portal page.

+1. It makes sense for mechanisms in this WG to describe client behavior requires for some functionality, such as “this network’s resolver has unique knowledge about domains X, Y, and Z” which can be ascertained. It does not make sense for us to drag user consent negotiation or signaling into this when CAPPORT already did lovely work to make captive portal discovery/negotiation easier for both parties. This hearkens back to my on-going point that “network policy involves more than just DNS and baking it into DNS is the wrong approach.”

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Thursday, April 1, 2021 2:39 PM
To: Deen, Glenn (NBCUniversal) <[email-masked]>
Cc: Vittorio Bertola <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

On Thu, Apr 1, 2021 at 4:47 PM Deen, Glenn (NBCUniversal) <[email-masked]<mailto:[email-masked]>> wrote:
If the network is going to prevent user opt-out it’s fully capable doing that regardless of the flag. However if it existed, this flag would permit the network to inform user to be aware of what is going on.

The network can already do this via free text in a human-readable captive portal page.

Arguments on the basis of RFC 8890 are not likely to be productive: I mention it mostly to emphasize that we are unlikely to reach consensus to adopt this sort of mechanism.

However, on this particular point, I think it's unrealistic to expect that most users have a meaningful choice of which network to use.  Users largely have no choice but to submit to whatever restrictions the network demands, so we should be very careful about what kinds of demands we endorse.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 1 Apr 2021 18:37:41 -0400

> However, on this particular point, I think it's unrealistic to expect that most users have a meaningful choice of which network to use.  Users largely have no choice but to submit to whatever restr…

Indeed.

And this is why the signal/threat does not add much value and falls in the “may contain peanuts” category - it’s a get out of jail free card at the enduser’s expense and normalizes network interference at the endusers’s expense.

In the case of an attacker (or even unknown network like a coffeeshop) it can also not be trusted from a privacy point of view. So at what point should the IETF recommend to ignore this new signal for their own safety versus complying with the network operator’s demands/friendly notification.

Paul

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Thu, 1 Apr 2021 22:43:53 +0000

*   No hat -

On 4/1/21, 3:38 PM, "Paul Wouters" <[email-masked]<mailto:[email-masked]>> wrote:

Indeed.

Paul

Let’s keep in mind the context of this discussion – It’s about Enterprise Split DNS – and not just connecting to a simple network.

-glenn

---

From: Paul Wouters <[email-masked]>
Date: Thu, 1 Apr 2021 21:11:35 -0400

> Let’s keep in mind the context of this discussion – It’s about Enterprise Split DNS – and not just connecting to a simple network.

My coffeeshop uses Enterprise WPA. What if they start using Enterprise Split DNS ? What is the expected UI for me to accept / decline this as enterprise network ? What if they announce Gmail.com is their enterprise domain ?

If the trust comes from enterprise MDM, why can’t the provisioning issue the domain list in a verified authenticated way, instead of adhoc untrusted network broadcasts ?

The document deems this problem solved by adding

The scope of this document is restricted to unmanaged BYOD devices
   without a configuration profile.  The unmanaged BYOD devices use the
   credentials (user name and password) provided by the IT admin to
   mutually authenticate to the Enterprise WLAN Access Point

And this is exactly the scenario where a coffeeshop that provides user/password is the distinguishable from a presumed trusted IT admin pre-arrangement with credentials.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Fri, 2 Apr 2021 08:18:07 +0000

On Thu, Apr 01, 2021 at 01:44:11PM -0400, Ben Schwartz wrote:
> "prescription".[1]  Whether this flag represents a demand to comply
> or a notice of enforcement, the effect is the same.[2]

you had me at [1] but lost me at [2]. there is no difference, but
neither side of "demand" vs. "notice" need be present. we express
policy for reasons of our own. those who do not follow the policy
do so at their own (unknown) risk. that's how the networks work,
of which the internet is a "network of".

> practice of network operators demanding access to all of their users'
> DNS activity, ...

no.

> ... i.e. browsing history.

and, no.

> That's out of scope for our working group.

if both antecedents held true, then this would be at least arguable.

> It also violates RFC 8890, "The Internet is for End Users".

RFC 8890 is not an internet standard. at least one member of the IAB has
taken the time to remind me that it is an individual submission; however,
had it not been, the mere fact that it was not a POISED-style standards
action makes it an opinion piece -- no matter whose opinion we think it is.

the internet is a network of networks, and that the networks of which the
internet is a "network of" are "for" a lot of purposes, and some might be
"for the users", or perhaps "for some users". others are "for some
investors" or "for national defense" or "for national security". i do not
ordain the IAB to tell me what my networks are for, nor by extension, to
tell me what the network of such networks (that is, "the internet") is for.
for the same reason the IAB cannot dictate to me my Acceptable Use Policy
or Peering Policy or Transit Policy or Firewall Policy, they could usefully
remain silent about what _my_ purpose is for building and operating (some
of) the networks that "the internet" is a network of.

i need a clear shot at every app, every device, every user, every OS, and
apparently now every protocol, which violates my network's stated policy.
i plan to hunt down every violator and fire it or them.

because "ADD" is a radical and controversial change to default behaviour,
my need for "a clear shot" has been placed very exactly in-scope.

-- 
Paul Vixie

---

From: tirumal reddy <[email-masked]>
Date: Mon, 5 Apr 2021 13:09:01 +0530

On Fri, 2 Apr 2021 at 06:41, Paul Wouters <[email-masked]> wrote:

>    - Let’s keep in mind the context of this discussion – It’s about
>    Enterprise Split DNS – and not just connecting to a simple network.
>
>
> My coffeeshop uses Enterprise WPA. What if they start using Enterprise
> Split DNS ? What is the expected UI for me to accept / decline this as
> enterprise network ? What if they announce Gmail.com is their enterprise
> domain ?
>

If a network lies about the ownership of a domain, it can be detected using
the mechanism discussed in
https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-10
.

Any unknown or untrusted network can use Enterprise WPA but the scope is
restricted to explicitly trusted networks by the user (see
https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-3
).

> If the trust comes from enterprise MDM, why can’t the provisioning issue
> the domain list in a verified authenticated way, instead of adhoc untrusted
> network broadcasts ?
>

MDM is not a possible option in several enterprise deployments.

> And this is exactly the scenario where a coffeeshop that provides
> user/password is the distinguishable from a presumed trusted IT admin
> pre-arrangement with credentials.
>

No, the scope of the document is restricted to explicitly trusted networks.

<snip>

   The scope of this document is restricted to unmanaged BYOD devices
   without a configuration profile and split DNS configuration on
   explicitly trusted networks.  In this use case, the user has
   authorized the client to override local DNS settings for a specific
   network.  It is similar to the way users explicitly disable VPN
   connection in specific networks and VPN connection is enabled by
   default in other networks for privacy.  The unmanaged BYOD devices
   typically use the credentials (username and password) provided by
   the IT admin to mutually authenticate to the Enterprise WLAN Access
   Point (e.g., PEAP-MSCHAPv2 [PEAP
<https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#ref-PEAP>],
EAP-pwd [RFC8146 <https://tools.ietf.org/html/rfc8146>], EAP-PSK
   [RFC4764 <https://tools.ietf.org/html/rfc4764>]).

</snip>

-Tiru

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

---

From: tirumal reddy <[email-masked]>
Date: Mon, 5 Apr 2021 13:37:00 +0530

> The network can already do this via free text in a human-readable captive

The user may or may not pay attention to the captive portal page content
and simply give consent. If the user does not read the long page content,
the flag helps to provide a targeted message to the user (similar to the
way Apple provides user-friendly privacy labels).

If the user reads the page content and agrees to use the network-designated
resolver by changing the OS setting not to use a pre-configured resolver in
the explicitly trusted network but not every app will use the OS DNS
configuration for various reasons. The flag helps the app developer for
troubleshooting, identifying malicious/misbehaving apps, notify the user of
the probable reasons for the app not working on the network etc.

-Tiru

---

From: Paul Wouters <[email-masked]>
Date: Mon, 5 Apr 2021 12:26:39 -0400 (EDT)

On Mon, 5 Apr 2021, tirumal reddy wrote:

> If a network lies about the ownership of a domain, it can be detected using the mechanism discussed in https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-10. 

note, it is very strange for the Security Considerations to define part
of the protocol designed. That part does not belong in the Security
Considerations section. It's not a consideration, it is part of the
protocol!

It states:

 	To comply with [RFC2826] the split-horizon DNS zone must either not
 	exist in the global DNS hierarchy or must be authoritatively
 	delegated to the split-horizon DNS server to answer.

This raises a few problems.

- The client needs to resolve the VPN internal domain externally to
   prove it is NXDOMAIN or not delegated. That means any network can
   trigger the client into doing those kind of lookups to malicious
   target domains, eg for tracking purposes
- It assumes DNSSEC for the proof, meaning there is no solution for
   domains without DNSSEC. It's completely spoofable.
- Most truly split corporate domains setup dummy placesholders for
   their internal zones. Or just create different views for their 2LD
   (eg different example.com internally and externally) and so in that
   case there is a public delegation and this scheme won't work.

> Any unknown or untrusted network can use Enterprise WPA but the scope is restricted to explicitly trusted networks by the user (see
> https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-3).
> 
> 

sure, but that is just re-stating my observation.

>    network.

As I explained, the coffeeshops will require that trust. Your protocol
will be used as something to coerce the enduser who has no choice but
to "trust" the network if they want access. It is just not going to work
in the real world to make this artificial distinction.

Note, as this can only be confirmed by the client when DNSSEC is enabled
on the public parent domain, presumbly there needs to be an internal
DNSSEC trust anchor too. How will this trust anchor be conveyed? We
went through a number of rounds with RFC 8598 for IPsec to prevent
VPN providers from installing (malicious) DNSSEC trust anchors that
could lead to TLSA records and other sensitive public key record types
in DNS from being redefined or taken over. The outcome was that
basically that list gets provisioned by the IPsec client setup.

As written, I just cannot support this document. It circles around all
security issues by stating the client trusts the server/network.

Paul

---

From: Andrew Campling <[email-masked]>
Date: Mon, 5 Apr 2021 19:17:56 +0000

Given the current interest in draft-reddy-add-enterprise-split-dns-01.txt on the list, some may find the presentation by Tiru and Dan on our weekly call last Monday, together with the ensuing discussion, of interest.  The recording is accessible at https://419.consulting/encrypted-dns/f/discovering-split-horizons. 

Andrew

-----Original Message-----
From: Paul Vixie <[email-masked]> 
Sent: 02 April 2021 09:18
To: Ben Schwartz <bemasc=[email-masked]>
Cc: tirumal reddy <[email-masked]>; ADD Mailing list <[email-masked]>; Tommy Pauly <[email-masked]>
Subject: Re: [Add] New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

On Thu, Apr 01, 2021 at 01:44:11PM -0400, Ben Schwartz wrote:
> "prescription".[1]  Whether this flag represents a demand to comply or 
> a notice of enforcement, the effect is the same.[2]

you had me at [1] but lost me at [2]. there is no difference, but neither side of "demand" vs. "notice" need be present. we express policy for reasons of our own. those who do not follow the policy do so at their own (unknown) risk. that's how the networks work, of which the internet is a "network of".

no.

and, no.

> It also violates RFC 8890, "The Internet is for End Users".

RFC 8890 is not an internet standard. at least one member of the IAB has taken the time to remind me that it is an individual submission; however, had it not been, the mere fact that it was not a POISED-style standards action makes it an opinion piece -- no matter whose opinion we think it is.

the internet is a network of networks, and that the networks of which the internet is a "network of" are "for" a lot of purposes, and some might be "for the users", or perhaps "for some users". others are "for some investors" or "for national defense" or "for national security". i do not ordain the IAB to tell me what my networks are for, nor by extension, to tell me what the network of such networks (that is, "the internet") is for.
for the same reason the IAB cannot dictate to me my Acceptable Use Policy or Peering Policy or Transit Policy or Firewall Policy, they could usefully remain silent about what _my_ purpose is for building and operating (some
of) the networks that "the internet" is a network of.

i need a clear shot at every app, every device, every user, every OS, and apparently now every protocol, which violates my network's stated policy.
i plan to hunt down every violator and fire it or them.

because "ADD" is a radical and controversial change to default behaviour, my need for "a clear shot" has been placed very exactly in-scope.

--
Paul Vixie

---

From: tirumal reddy <[email-masked]>
Date: Wed, 7 Apr 2021 18:30:29 +0530

On Mon, 5 Apr 2021 at 21:56, Paul Wouters <[email-masked]> wrote:

> enterprise network ? What if they announce Gmail.com is
> > their enterprise domain ?
> >
> >
> > If a network lies about the ownership of a domain, it can be detected
> using the mechanism discussed in

Yes, we plan to fix it in the next revision.

>    prove it is NXDOMAIN or not delegated.

No, 02 version of the draft does not rely on NXDOMAIN or NSEC3 response.

> That means any network can

The DNS client only performs a NS lookup to check the authority over the
domains. Further, the endpoint does not automatically resolve the domains
and download the content. Most importantly, the user may or may not visit
the domains in the DnsZones.

I don't see a privacy leakage problem or security issue because of
malicious domains.

>    domains without DNSSEC. It's completely spoofable.

If the client uses an encrypted DNS connection to a pre-configured public
resolver, DNSSEC is not mandatory. DNSSEC is only required when the
network-designated resolver is used to detect spoofed responses.

>    case there is a public delegation and this scheme won't work.

No, it works for both private domains and global domains but with a
different version on its internal network.
Please explain why the proposed mechanism does not work for global domains ?

> in the real world to make this artificial distinction.

Some Enterprise networks already block access to public resolvers (e.g.,
DNS servers performing filtering can categorize DoH servers in the “Proxy /
Anonymizer” content category, see
https://umbrella.cisco.com/blog/doh-dns-over-https-to-block-or-not-to-block)
and can possibly use a captive portal to notify the user to use the
network-designated resolver. If a coffee shop wants to force the endpoint
not to use public resolvers, it can use a DNS filtering server to block the
“Proxy / Anonymizer” category or if destination IP addresses of flows from
the endpoint are not in the DNS cache, it can block those flows.

The draft currently says the following:

The SplitDNSAllowed key value set to false is an internal security policy
expression by the operator of the network but is not a policy prescription
to the endpoints to disable use of DNS servers not provided by the network.
If SplitDNSAllowed is set to false, the client MUST NOT trust the
SplitDNSAllowed key in case of connecting to unknown or untrusted networks
(e.g., coffee shops or hotel networks).  Most importantly, the endpoint can
choose to use an alternate network to resolve the global domain names.

> basically that list gets provisioned by the IPsec client setup.

In this scenario, I don't see the need to override the trusted certificates
for TLS or install Enterprise CA certificates.

> security issues by stating the client trusts the server/network.

No, clients do not blindly trust explicitly trusted networks. If a network
lies about the ownership of a domain, it can reject the network entirely
(because the network lied about its authority over a domain).

-Tiru