Paul Wouters wrote on 2021-11-25 15:36:
On Thu, 25 Nov 2021, Paul Vixie wrote:
...
This is deeply concerning statement, even if you are trying to convince
the authoritarians that they should let the DNS answer slide through
"in their best interest".
any belief that too much effort will at some point cause authoritarian
network operators (including myself, most large enterprises, and many
national governments) to give up and let the spice flow where it may, is
naive or pretense. we should adopt some nuance, and figure out what the
real shape of the real negotiating table is, and start working towards
an equilibrium. these ships will NOT pass in the night.
In fact, a much better answer here would be to develop a DNS protocol
that would prevent those kind of authoritarian network operators to
get any visiblity at all in what their citizens are doing. Luckily,
there is a good protocol for that, DoH. I hope it sees widespread use
over too many hostnames to track and block.
right now DoH is pretty easy to detect and block. that'll change, as DoH
adopts cover traffic and other Tor-style trickery. eventually it'll be
nec'y to block some traffic at the IP (packet) layer even if that cuts a
network operator off from important CDNs. later, it'll become nec'y to
block all outbound packet traffic and insist that an edge proxy with a
local crypto key be used. no managed private network operator can afford
to "just say yes." _their network means their rules_ just as it did when
unsolicited traffic (spam, DDoS) first crawled out of the muck.
the more the internet tries to make itself viral, the more abuse we'll
see from surveillance capitalists (including a lot of IoT) and botnets
and intruders and malicious insiders and malware, all of whom are hoping
to get the treatment that's being planned by digital activists for
political dissidents. this will cause escalation by defenders. the end
game is that the internet stops at the border of each managed private
network, and signals are regenerated after being analyzed.
i'm speaking of inevitabilities here not aspirations, so please don't
shoot the messenger. the world is the way it is for reasons, and unless
we learn how the world is and why, we had better worry about unintended
consequences of digital signal activism. adult negotiation starts with
the middle ground of the possible and only uses shows of force to avoid
corners and edges. the IETF is not doing this, which will lead us
through wasted time and missed better outcomes.
probably this just means packing the original answer and the policy
signature into EDNS in some way. but the response itself will have to
have the policy-trampled answer and rcode (likely NXDOMAIN but not
always.)
This has a similar effect as moving the RRs from Answer to Authority
section, and sure has a little better signaling support although if
this is not coming directly from the application, they might not see
the EDNS option either. ...
the signal path from the authority to the stub must pass through many
networks, some of which are public (commercial ISPs) or otherwise policy
agnostic (many universities and many families). to the extent that some
signal patterns are unacceptable to some on-path operators, we should
make transactions and outcomes including policy-trampling as transparent
as we can. hiding stuff because you consider on-path actors to be
hostile is going to seem, well, hostile.
... So sadly this would be a reason to move DNS into applications,
something which I wish we could stop doing.
that last topic is one for the ADD WG which i know that you (wouters)
are actively aware of and participating in, but for the benefit of
others here: see <https://datatracker.ietf.org/wg/add/about/>. one topic
currently under discussion there is how a network operator can signal
its resolver policy -- partly because operators of managed private
networks want to be sure that an endpoint who does not follow that
policy is behaving intentionally and with forethought. this helps guide
and prioritize our enforcement activities.
--
vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
