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

[Paul Vixie <[e-mail]>]

On Sat, Mar 13, 2021 at 09:43:36AM -0500, Paul Wouters wrote:
> On Mar 12, 2021, at 20:08, Stephen Farrell <[e-mail]> wrote:
> >> 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.

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.

> > FWIW, I think the above is correct. That said, we have some
> > 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?

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

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