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

[Ben Schwartz <[e-mail]>]

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=
[e-mail]> wrote:

>
>
> > Il 15/03/2021 03:13 Paul Vixie <[e-mail]> ha scritto:
> >
> > 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.
>
> 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
> [e-mail]
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>