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

From: tirumal reddy <[email-masked]>
Date: Thu, 11 Mar 2021 11:56:20 +0530

The revised draft
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-01
addresses
comments from Ben. Further comments and suggestions are welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, 11 Mar 2021 at 11:54
Subject: New Version Notification for
draft-reddy-add-enterprise-split-dns-01.txt
To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]>

A new version of I-D, draft-reddy-add-enterprise-split-dns-01.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-add-enterprise-split-dns
Revision:       01
Title:          Split-Horizon DNS Configuration in Enterprise Networks
Document date:  2021-03-10
Group:          Individual Submission
Pages:          12
URL:
https://www.ietf.org/archive/id/draft-reddy-add-enterprise-split-dns-01.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns
Htmlized:
https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-add-enterprise-split-dns-01

Abstract:
   When split-horizon DNS is deployed by an enterprise, certain
   enterprise domains are only resolvable by querying the network-
   provided DNS server.  DNS clients which use DNS servers not provided
   by the network need to route those DNS domain queries to the network-
   provided DNS server.  This document informs DNS clients of split-
   horizon DNS, their DNS domains, and is compatible with encrypted DNS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Mar 2021 14:02:04 -0500

Thanks for the updates.  Some comments

Section 6:

>    If an Enterprise network restricts all the DNS queries to be sent to
>    the network-provided DNS server, SplitDNSAllowed will be set to
>    false.

This is clearly a policy prescription, and is out of scope.  I think this
key should be removed from the draft.

> [RFC7149] recommends validation of responses using NSEC3.

Nit: RFC 7129.

Broader note: I think it would be better to drop the "private-only" flag,
as well as the NSEC test and top-domains list.  While this arrangement of
claiming domain names that are known not to exist globally is possibly
allowed by RFC 2826, I don't think it's a good practice.  For example,
there is no such domain as "login.citibank.com", but I think it would be
bad security practice (and also a bad architecture) to allow networks to
claim that name.

Note that private-only names are still supported.  If the local resolver is
authoritative for corp.example.com, it can serve queries for
login.corp.example.com, even if login.corp.example.com is NXDOMAIN when
queried externally.

On Thu, Mar 11, 2021 at 1:26 AM tirumal reddy <[email-masked]> wrote:

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Mar 2021 10:30:24 -0800

Ben Schwartz wrote on 2021-03-11 11:02:
> This is clearly a policy prescription, and is out of scope.  I think
> this key should be removed from the draft.

it's a policy expression, not a policy prescription. some networks have
rules, and of those, some networks have this rule. the draft makes and
should make no recommendation as to what keys be used -- that would be
prescriptive. however, the expression of policy is not prescriptive but
rather descriptive. i oppose removal of this key from this draft.

vixie

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 12 Mar 2021 11:00:11 -0800

> On Mar 11, 2021, at 11:02 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> This is clearly a policy prescription, and is out of scope.  I think this key should be removed from the draft.

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

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.

Tommy
> Broader note: I think it would be better to drop the "private-only" flag, as well as the NSEC test and top-domains list.  While this arrangement of claiming domain names that are known not to exist globally is possibly allowed by RFC 2826, I don't think it's a good practice.  For example, there is no such domain as "login.citibank.com <http://login.citibank.com/>", but I think it would be bad security practice (and also a bad architecture) to allow networks to claim that name.
> 
> Note that private-only names are still supported.  If the local resolver is authoritative for corp.example.com <http://corp.example.com/>, it can serve queries for login.corp.example.com <http://login.corp.example.com/>, even if login.corp.example.com <http://login.corp.example.com/> is NXDOMAIN when queried externally.
> 
> On Thu, Mar 11, 2021 at 1:26 AM tirumal reddy <[email-masked] <mailto:[email-masked]>> wrote:
> The revised draft https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-01 <https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-01> addresses
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt
> To: Tirumaleswar Reddy.K <[email-masked] <mailto:[email-masked]>>, Dan Wing <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/archive/id/draft-reddy-add-enterprise-split-dns-01.txt <https://www.ietf.org/archive/id/draft-reddy-add-enterprise-split-dns-01.txt>
> Status:         https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/ <https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns <https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns>
> Htmlized:       https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-01 <https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-01>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-add-enterprise-split-dns-01 <https://www.ietf.org/rfcdiff?url2=draft-reddy-add-enterprise-split-dns-01>
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
> -- 
> Add mailing list
> [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Mar 2021 19:18:35 +0000

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

-- 
Paul Vixie

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 12 Mar 2021 21:24:43 +0000

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

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.

> 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.
> 
> 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.
> 
> 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
> [email-masked]
> 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

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 12 Mar 2021 15:50:08 -0800

> On Mar 12, 2021, at 11:18 AM, Paul Vixie <[email-masked]> wrote:
> 

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

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Sat, 13 Mar 2021 00:19:51 +0000

- No hat -

One Q inline.

[Glenn] Who is setting this bit? And where in the interaction is it set?     What I mean here is there is the VPN client on the device - is it setting this bit or is it the VPN itself that is setting this bit?  If it's the VPN client wouldn’t a on device communication be both better and more trustworthy as it isn't being touched by anything on the wire?

[Glenn]. Perhaps I'm not understanding the split between the VPN client on the device and the perspective of the "network".

-glenn

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Mar 2021 01:07:52 +0000

Hiya,

On 12/03/2021 21:24, Tommy Jensen wrote:
> 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.
FWIW, I think the above is correct. That said, we have some
serious obstacles in the way of figuring out how to do that.
For example, I don't think we even know the potential set of
possible policies for when there's a "smart speaker" and a
house-guest involved, never mind how to possibly represent,
secure and process those in some electronic format.

There is also a danger that we encode our last decade's idea
of policy into a protocol in such a way that we make it hard
to move beyond that in the next decade. That doesn't mean we
ought ignore 2010-style policies but I think it does imply a
lot of care ought be taken before we follow the "obvious"
route for expressing those "obvious" policies.

So, I'd also argue for extreme minimalism in ADD on the
dual basis that we really don't yet know what's right for
the near future while at the same time we can be pretty
confident that the set of policies that were used in the
recent past and that are still validly used likely isn't
quite the right guide.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 13 Mar 2021 09:43:36 -0500

> serious obstacles in the way of figuring out how to do that.

Agreed. And this was clear when discussing the charter.

> secure and process those in some electronic format.

One feature of Apple that is great is the ability for phones to communicate if you are in each other’s address book. It is used to share the wifi password when my friends visit when they try to join the network.

It would be great if something like that is standardized and with options for the network owner to give out access to specific devices like TV, security cameras, etc.

Making special rules for DNS doesn’t seem to address the issues of real users. I suspect we are reaching the point soon where we don’t really want to join random networks for just internet access - we would only do it to reach certain devices otherwise not reachable.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Mar 2021 02:13:12 +0000

> >> from an attacker, it should be more general than DNS and it should be

is that a nice to have or is that a got to have? for me it's the former, and
if there were an effort underway by ambitious commited qualified distributed
system architects to create the former, i would want to join with them. but
no such effort is underway, and so i think it's a false choice -- it's like
a proverbial winged pig, with which pigs could fly, but they can't, so we
ought to constrain our thinking to something which actually _can_ be done.

a handset's inability to reliably know whom to trust on the local network can
be worked around. for example it's already trusting DHCP and SLAAC, so adding
more variables to those handshakes is not unreasonable. for another example
the in-addr space for the network as defined by RFC 1101 or for the exit
gateway as defined by RFC 1034 can be confidently assured to to under the
control of the network operator, so new variables could also be lodged there.

> > serious obstacles in the way of figuring out how to do that.

the seriousness of those obstacles should be compared and contrasted with the
seriousness of deciding that since pigs don't have wings we must not try to
use some other life form that actually can fly in order to accomplish a goal
desired by many. i should reiterate my desire for a way to build more trust
faster for local network policy matters, but also my willingness to put that
desire in context among the hierarchy of costs and benefits of alternatives.

> Agreed. And this was clear when discussing the charter.

i chose this re-entry point back to this thread because i'd really like to
know more specifically what you're agreeing with, and also if in light of my
remarks herein, your agreement might be more nuanced than you first believed?

> > secure and process those in some electronic format.

i think we could enumerate a set of policies which would seem complete to
those in this forum at this time, which would be subject to later revision
like all internet protocols. the cost of addressing this challenge is to me
far less than the cost of ignoring it or punting it down-road. can we try?

> One feature of Apple that is great is the ability for phones to communicate
> if you are in each other???s address book. It is used to share the wifi
> password when my friends visit when they try to join the network.

if we were looking at the larger problem (larger than what DNS needs today)
i'd want to explore such options. if we knew that the relying party and the
resource had human interfaces, we could do what bluetooth does when i bring
my smart phone to my car for "pairing". but we not only won't always have
human interfaces, we also won't always have humans. so this is a very large
problem and won't be solved on the ADD WG's timeline.

> It would be great if something like that is standardized and with options
> for the network owner to give out access to specific devices like TV,
> security cameras, etc.
> 
> Making special rules for DNS doesn't seem to address the issues of real
> users. I suspect we are reaching the point soon where we don't really want
> to join random networks for just internet access - we would only do it to
> reach certain devices otherwise not reachable.

in fact, this counterpoint seems even more vital than the thread that got us
here. internet access is now often free (in monetary terms) because the
provider either wants to sell you coffee or a hotel room, or wants to watch
what you do online for political or capitalist surveillance. while we cannot
expect every user to trust every attestation by every network operator, we
should imagine some kind of web of trust whereby the operator's certificate
might be itself certified by an upstream authority. for example if apple or
google who are the makers of my smartphones attest to the trustworthiness of
some network operator to speak truth to me about their surveillance policies,
i would be inclined to believe those attestations.

in any case that's off-topic no matter how compelling, and i'd like to reduce
this thread to the question of how we could usefully address in this WG. for
that we should be concerned with how a device can learn the local network's
policy in a way that's trustworthy enough to make a use / don't-use decision
for the network, and a follow / don't follow decision for its stated policies.

* * *

in a historic oversight, RFC 2317 failed to explicitly update RFC 1101, and
so the implementation of the later has to apply the implication of the former.
as part of the CIDRD effort i actually did implement this in getnetbyaddr()
in the BSD 4.4 libc, and it worked fine. i think if we applied the mappings
described in RFC 1101 [3.2, 3.3] we could easily add a well-known subdomain
along the lines of "_rdns._policy" which could contain a TXT RRset that
explained this network's recursive-dns access policies in pidgin form. if a
relying party has reason to fear fraud, it would only believe such expressions
if they were signed with DNSSEC.

that's not a full proposal but it does show the triviality of the problem some
members of this forum say they are trying to avoid because of nontriviality.
i would welcome further discussion along those lines, but i will likely not
welcome further dismissal of the ask due to the unstated cost of the tell.

-- 
Paul Vixie

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 15 Mar 2021 10:12:23 +0100 (CET)

> Il 15/03/2021 03:13 Paul Vixie <[email-masked]> ha scritto:
> 
> more variables to those handshakes is not unreasonable.

If you think at it, DHCP's purpose is exactly to let networks communicate policies to devices when they join them: "you must use the following IP address to communicate" and "you can use the following DNS resolvers to resolve names" are examples of policy messages that are currently transmitted. As an immediate step, we could just add new messages such as "you must not use any DNS resolver other than the ones I just suggested to you", which of course clients would then be free to decide whether to accept or ignore.

Whether DHCP is adequate as a mechanism (in terms of security, for example) is then a different story; most of the world doesn't seem to have problems with it, but one could indeed think of replacing it with something else, for example something that can express in authenticated ways who is the owner of the network. I am not familiar with this space so I don't know if anything was attempted already, but that could indeed be a longer term effort worth pursuing.

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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 15 Mar 2021 11:09:32 -0400

Many have raised the difficulty of establishing an identity for the network
and confirming that claims received by the client were produced by the
network operator.  That is a challenge, but it is not my principal
concern.  My main concern is that when we move from encoding what the
network offers to what it "allows", we are discussing the IETF blessing
certain Terms of Service as technical standards.

Terms of Service are a thoroughly human, legal construct, not a mechanical
handshake.  They represent an unbounded conceptual space that cannot be
neatly quantized into an IANA registry.  Their interpretation is subject to
social norms and judges' rulings.  Does "splitDNSAllowed: false" forbid the
use of corporate VPN tunnels?  DNS entries already in cache?  mDNS? Using
"dig" over SSH?  Alternate DNS servers if needed due to a medical
emergency?  Namecoin?  Does ignoring this JSON blob constitute a violation
of the US Computer Fraud and Abuse Act?  I don't want answers; I want to
make sure that we don't have to ask these questions.

Standardizing Terms of Service opens Pandora's Box.  The list of things
that someone somewhere wants to tell a user not to do on their network is
endless, and the IETF should not be in the business of judging which of
these requests are appropriate.  (And we surely must judge, as some
requests are clearly unconscionable.)

As a practical matter, no such request can command IETF consensus, nor the
consensus of this working group.  That's why the ADD charter goes to some
length to remind us not to be distracted by them.

If you want to invest in improving network identity attribution, let's
ensure that when users are reviewing the network's Terms of Service, they
know exactly who the network operator is.

On Mon, Mar 15, 2021 at 5:12 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> If you think at it, DHCP's purpose is exactly to let networks communicate
> policies to devices when they join them: "you must use the following IP
> address to communicate" and "you can use the following DNS resolvers to
> resolve names" are examples of policy messages that are currently
> transmitted. As an immediate step, we could just add new messages such as
> "you must not use any DNS resolver other than the ones I just suggested to
> you", which of course clients would then be free to decide whether to
> accept or ignore.
>
> Whether DHCP is adequate as a mechanism (in terms of security, for
> example) is then a different story; most of the world doesn't seem to have
> problems with it, but one could indeed think of replacing it with something
> else, for example something that can express in authenticated ways who is
> the owner of the network. I am not familiar with this space so I don't know
> if anything was attempted already, but that could indeed be a longer term
> effort worth pursuing.
>
> --

---

From: Andrew Campling <[email-masked]>
Date: Mon, 15 Mar 2021 15:33:17 +0000

On Mon, Mar 15, 2021 at 15:10 Ben Schwartz [email-masked]<mailto:[email-masked]> wrote:

> Standardizing Terms of Service opens Pandora's Box.  The list of things that someone somewhere wants to tell a user not to do on their network is endless, and the IETF should not be in the business of judging which of these requests are appropriate.  (And we surely must judge, as some requests are clearly unconscionable.)

> As a practical matter, no such request can command IETF consensus, nor the consensus of this working group.  That's why the ADD charter goes to some length to remind us not to be distracted by them.

Given that the thread that elicited the above response included the disclaimer “which of course clients would then be free to decide whether to accept or ignore”, IMHO the suggestion is within the scope of the charter, ie focusing on the need to convey such information and not straying into a debate about whether and how such information should be acted upon.

Andrew

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Mar 2021 09:22:53 -0700

I agree with Ben here. This seems out of scope.

-Ekr

On Mon, Mar 15, 2021 at 8:10 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> Many have raised the difficulty of establishing an identity for the
> network and confirming that claims received by the client were produced by
> the network operator.  That is a challenge, but it is not my principal

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 16 Mar 2021 08:10:15 +0100 (CET)

>     Il 15/03/2021 16:09 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
> 
>     Many have raised the difficulty of establishing an identity for the network and confirming that claims received by the client were produced by the network operator.  That is a challenge, but it is not my principal concern.  My main concern is that when we move from encoding what the network offers to what it "allows", we are discussing the IETF blessing certain Terms of Service as technical standards.
> 
>     Terms of Service are a thoroughly human, legal construct, not a mechanical handshake.  They represent an unbounded conceptual space that cannot be neatly quantized into an IANA registry.  Their interpretation is subject to social norms and judges' rulings.  Does "splitDNSAllowed: false" forbid the use of corporate VPN tunnels?  DNS entries already in cache?  mDNS? Using "dig" over SSH?  Alternate DNS servers if needed due to a medical emergency?  Namecoin?  Does ignoring this JSON blob constitute a violation of the US Computer Fraud and Abuse Act?  I don't want answers; I want to make sure that we don't have to ask these questions.
> 
As I understand, we can at least develop the mechanism for transport of such information. As for the meaning, an indication that the network uses its own resolvers for network management purposes and would like applications to never use any other resolver (exactly like Mozilla's canary domain mechanism, just with a different transport) is not ambiguous and does not require any policy discussion, as "never" means "never"; it is then up to the client to decide whether to take it literally, to take it with some freedom, or not to take it at all - and while doing this, to evaluate any legal and policy implication in the specific context.

I don't see the need to standardize the meaning of this signal up to the level of detail that you envisage, but if that were required, I agree that it should not happen here. That kind of standardization of terms of service usually happens either under the form of industry certification/classification schemes, or by agreeing on industry-wide guidelines, or by regulation.

> 
>     If you want to invest in improving network identity attribution, let's ensure that when users are reviewing the network's Terms of Service, they know exactly who the network operator is.
> 
That would also be useful.

--

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Mar 2021 12:44:55 +0100

Hi Ben

OT (I think)…

I haven’t been following much of this thread,  I tend to lose interest/consciousness when debates on this list go sideways, but….

> On 15 Mar 2021, at 16:09, Ben Schwartz <bemasc=[email-masked] <mailto:bemasc=[email-masked]>> wrote:
> 
> Standardizing Terms of Service opens Pandora's Box.

<Creeeeeeeaaaak>

> The list of things that someone somewhere wants to tell a user not to do on their network is endless, and the IETF should not be in the business of judging which of these requests are appropriate.  (And we surely must judge, as some requests are clearly unconscionable.)

I don’t think TOS differences are all that endless. TOS/AUPs are pretty standardized these days, modulo jurisdictional differences.  Where things tend to vary is in enterprise policy, and THAT is all over the map.

Eliot

Eliot

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Mar 2021 02:58:01 +0000

> I agree with Ben here. This seems out of scope.

eric, can you give an example of some feature which could be proposed that
you'd find in-scope even though it lacked full throated unalloyed
amplification of the tenets and goals of RFCs 8890, 7624, and 7258?

i ask, because ADD signifies a controversial sea-change to the way DNS has
always been treated, and if some additional signaling would reduce that
controversy for a class of on-path actors who are not third parties, then that
signaling would be in-scope.

i'd hate to think that anyone here had a political agenda which influenced
their technical recommendations. generally speaking, a modern RFC protocol
says "if you want to do _this_, here's a way to do it interoperably." while
"prevent interference by on-path actors" is not a form of interopability,
i think that "publish and consume machine-readable RDNS policy" would be.

as ben mentioned up-thread, one salient use of such signaling would be
better error messages toward end-systems when their prefered RDNS access
method does not work. the alternative is silent failure (bad engineering).

-- 
Paul Vixie

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Mar 2021 03:27:29 +0000

Hiya,

A question (*)...

On 17/03/2021 02:58, Paul Vixie wrote:
> generally speaking, a modern RFC protocol
> says "if you want to do_this_, here's a way to do it interoperably." while

Don't you think that ossification due to often not-often
updated middleboxes has an effect on interoperability? I
thought that was a more-or-less accepted proposition, but
perhaps it's not.

ISTM if one does accept an "aged middlebox breaks things"
argument, then "interference by on-path actors" is clearly
one of the barriers to interoperability we face. (At the
same time, I do not claim all interference by on-path actors
is "bad" - there are some benefits to firewalls, even if
those also often become brittle, e.g. due to out-dated
configs.)

To be clear: I'm not myself sure how middlebox arguments
affect ADD - on one view, they don't, as we're talking here
about stub<->recursive interactions, but OTOH, the "<->"
there can involve a few hops in various ways, so it's
quite possible that someone may view some of those boxen
as middlenboxen.

Thanks,
S.

(*) To be honest, mine is maybe as loaded a question as if
I'd described things as "full-throated" or wondered about
flying pigs etc. But FWIW, I don't mind a bit of rhetoric
at all:-)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Mar 2021 07:21:56 +0000

On Wed, Mar 17, 2021 at 03:27:29AM +0000, Stephen Farrell wrote:
> > generally speaking, ...

it is. but not all continuity is ossification. sometimes things work the
way they should, or at least work the way people who making informed choices
have deliberately chosen. (even if that "way" happens to have continuity.)

> one of the barriers to interoperability we face.

it sometimes is, but sometimes is not. consider for example a firewall, by
which a network administrator might qualify as an on-path interferer. that
certainly breaks some stuff, but it's not a form of non-interoperability --
it's a form of policy. and if the firewall operator has obligations to the
server operators or to the end users which obligations do require that
policy, then i think their policies should not be trivially dismissed.

DoH as an example deliberately and intentionally prohibits firewalls from
restricting or obstructing off-network RDNS. it says so on page 1 of the
RFC -- they don't try to hide it. those of us figuring out how to cope
with a world where firewalls are deliberately and intentionally prohibited
by IETF protocol standards action may ask for some new signaling to support
our (continuing) obligations.

> (At the same time, I do not claim all interference by on-path actors
> is "bad" - there are some benefits to firewalls, even if those also
> often become brittle, e.g. due to out-dated configs.)

thanks for this. to me the foundational principle is that networks have
"policy autonomy" and if operators screw things up, they have themselves
to blame and their employees, customers, or families can blame them also.
to be clear, this means there is no "but", no exception whereby well
meaning software suppliers or internet protocol designers can say "yes,
it's your network, but we can't allow you to set policy for it."

however, i lost that argument, so now i'm just trying to limit the damage,
which is why i'm asking for a policy signal path whereby any device which
does not obey the local network's policy can be presumed hostile to that
policy -- ignorance won't be an excuse. i've already removed all mozilla
corporation software from my networks on the basis of their DoH theatrics,
but there will be others who don't believe that on my network, my rules
actually matter.

> (*) To be honest, mine is maybe as loaded a question as if I'd described
> things as "full-throated" or wondered about flying pigs etc. But FWIW, I
> don't mind a bit of rhetoric at all:-)

thanks for this, too. i don't aim for outlandishness; it simply finds me.

-- 
Paul Vixie

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 18 Mar 2021 11:46:22 -0400

> policy, then i think their policies should not be trivially dismissed.

This is an important point that I think may be lost in some conversations.
Many of the
obligations are based on a number of potential factors including corporate
policy, regulatory,
service provider contractual / service terms and end user (e.g. parents)
needs.

In each of those cases, the point of policy control is with party that has
the obligation or whom they
have directly delegated the responsibility.   Also, often times these
obligations are based on where
you are physically (which building/location,country, etc) and not based on
what service you are trying
to reach or use.

Examples of obligations: (1) obligations on protecting privacy data under
GDPR, (2) corporate policy limiting
what a user can reach/do based on employment terms and conditions.

> it's your network, but we can't allow you to set policy for it."

In line with this and my response higher up in the chain, enforcement of
policy is important.
The other point in her is the route to escalation and resolution.

No matter what is built and/or created, there is a non-trivial amount of
support required
to resolve issues inherent in technology and deployments.  Operators,
enterprises are filled
with support teams who respond to customer/user issues and are held
accountable to resolve
problems.   Having needed tooling and a working support stratum is
essential to delivering service to users.

> but there will be others who don't believe that on my network, my rules

Seems reasonable in that is attempts to remove breakage while addressing
the requirement stated (network/administrator policy).

regards,

Victor K

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Mar 2021 21:09:27 -0700

Ben Schwartz wrote on 2021-03-15 08:09:
> network and confirming that claims received by the client were produced
> by the network operator.

who? (the many) what? (did they say) and why not? (wouldn't we just use
a signal pattern that only the network operator, and not every node on
that network, could participate in?)

i don't intend to be abrupt. but "many people are saying" is not an
argument, and i don't think a non-argument should move the needle here.

> That is a challenge, but it is not my
> principal concern.  My main concern is that when we move from encoding
> what the network offers to what it "allows", we are discussing the IETF
> blessing certain Terms of Service as technical standards.

not at all -- not even a little. the internet is a network of networks,
and the networks are considered by the core to be autonomous. a protocol
by which the network operator expresses policy (not terms) would aid in
interoperability.

* * *

i hope you can clear something up for me, though. previously your
principle concern was that RDNS policy was a small part of a larger
puzzle, and you were reluctant to treat it independently. i answered
that i wanted the same pony you did, but in the absence of anyone who
wanted to work on the whole puzzle, we had to consider starting small
with the small part of the puzzle we're facing.

you'd also said that there wasn't a way that the network operator could
speak authoritatively and that a client might receive policy from some
other node and would not know whom to trust, so i suggested a way to
signal the policy (TXT records under the IN-ADDR.ARPA tree) which could
be considered authoritative in any case, and could also be DNSSEC signed.

now your principle concern has changed. it seems that this concern could
have been stated earlier, in a brace with the others. could you supply a
complete list of your concerns, such that if addressed, you would not
object? because without that you run the risk of bad optics ("moving the
goalposts") and the suspicion that your objections aren't resolvable.

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Mar 2021 21:32:41 -0700

Tommy Pauly wrote on 2021-03-12 15:50:
>> 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 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

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 20 Mar 2021 07:56:41 +0100

> "many people are saying" is not an

Specifically, it’s a logical fallacy, argumentum ad populum, and logical fallacies don’t move the needle. 

https://yourlogicalfallacyis.com/bandwagon

> have been stated earlier, in a brace with the others.

Specifically:

https://yourlogicalfallacyis.com/special-pleading

Paul is right. If you have an argument to make, please produce it. 

> could you supply a
> object? 

This, on the other hand, combines elements of a tu quoque, a burden-of-proof, and a composition.  It probably has a name of its own that I’m not remembering at the moment. Ben is not obligated to produce every valid argument simultaneously, and not doing so is not a weakness or sign of bad faith. Reasonable arguments may be discovered in the course of good-faith exploration of the topic.

Having now duly ingratiated myself with all parties, I’ll shut up. 

                -Bill

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 22 Mar 2021 22:31:24 -0400

> argument, and i don't think a non-argument should move the needle here.

Evidently I should have been clearer: I meant "many in this thread".  I
count at least three messages to that effect from different authors in this
thread.

> with the small part of the puzzle we're facing.

I suppose this is in reference to
https://mailarchive.ietf.org/arch/msg/add/LAChEeAQa9_0zDEbPWhshYgEuGo/
I think I meant something quite similar to what I said earlier in this
thread: policy is a conversation between people, not machines, so the
logical place for it is in something more or less like a captive portal
ToS, where the user may contemplate all of the network's policies together.

In any event, the place for it is not in this working group.

> other node and would not know whom to trust

I just took a few minutes to re-read every message I've sent to this list
in the last two years.  I did not find anything matching this description.
Nonetheless, it's possible that I may have said something to this effect.

My current feeling, as I said earlier in this thread, is that this is a
significant challenge, but I do not mean to claim that it is impossible.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Mar 2021 02:58:49 +0000

Hiya,

> ToS, where the user may contemplate all of the network's policies together.

Really? That doesn't seem defensible to me fwiw.

Do you have an example of such a ToS description that is
really a conversation between people? I can't think of one.

While I don't agree with Paul V. that this WG ought try
describe complex policies (and in particular I think we
ought not attempt to reduce current policies to PDUs used
when discovering DNS server features), the idea that a
person has an opportunity for a discussion with another
person whilst accessing a network via a captive portal
seems fictional at best.

But maybe you meant something else or I'm just confused?

Ta,
S.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Mar 2021 10:14:07 -0400

> really a conversation between people? I can't think of one.

I certainly don't mean to claim that clickwrap licenses are the ideal way
for these people to interact.  I just don't think we're likely to make them
better by encoding bits of them in JSON.

I also think this topic is out of scope, and unlikely to be productive.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 30 Mar 2021 11:09:24 +0530

Hi Ben,

Please see inline

> key should be removed from the draft.

It is only a policy expression and definitely not a policy prescription.
Updated the draft to clarify.

> as well as the NSEC test and top-domains list.
>

Yes, removed all of the above in 02 revision.

> While this arrangement of claiming domain names that are known not to
> exist globally is possibly allowed by RFC 2826, I don't think it's a good
> practice.  For example, there is no such domain as "login.citibank.com",
> but I think it would be bad security practice (and also a bad architecture)
> to allow networks to claim that name.
>
> Note that private-only names are still supported.  If the local resolver
> is authoritative for corp.example.com, it can serve queries for

Agreed, please see
https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-02#section-10
.

Cheers,
-Tiru

>> To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]
>> >
>>
>>
>>

---

From: tirumal reddy <[email-masked]>
Date: Tue, 30 Mar 2021 12:33:17 +0530

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

>
>
> On Mar 11, 2021, at 11:02 AM, Ben Schwartz <
> bemasc=[email-masked]> wrote:
>
> 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 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.
>
> 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.
>

Good point, the flag is particularly useful when the client does not use
DNS lookup to reach the DNS servers not provided by the network. For
example, the client can be pre-configured with both the domain name and IP
addresses of the public resolver or is pre-configured with the IP address
of the resolver which uses IP address in the certificate as identifier.  In
this case, the extended error codes defined in RFC8914 cannot be returned
to the client to provide additional information about the cause for the
block.

-Tiru