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

[Eric Rescorla <[e-mail]>]

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

-Ekr


On Mon, Mar 15, 2021 at 8:10 AM Ben Schwartz <bemasc=
[e-mail]> 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
> 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
>>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>