Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"

[Paul Ebersman <[e-mail]>]

acampling> In the DNS section, it is disheartening to read the IAB
acampling> stating that "[a DNS resolver] returning the wrong (or no)
acampling> address breaks the trust that users have in this
acampling> infrastructure", after having spent months on the ADD list
acampling> and elsewhere to explain that there are indeed lots of use
acampling> cases in which users expect, or even actively request, that
acampling> their resolver applies filters to the responses. In some
acampling> cases it is actually the opposite - if I acquire a DNS-based
acampling> service to prevent any accidental connection to
acampling> malware-infected websites and then I get malware, that's when
acampling> I lose trust in my DNS resolver; same for parental controls.

acampling> I believe that the broad assertion that ``all DNS filtering
acampling> is wrong'' suggests a lack of understanding in the way that
acampling> many users and entities use DNS as a control surface in a
acampling> variety of contexts.  There are large classes of users that
acampling> would disagree with the insistence that a DNS resolver must
acampling> return the correct address in every case.

Yes. A recent post from Hugh Dixon in the ADD list quotes RFC 7258:

   "Pervasive Monitoring (PM) is widespread (and often covert)
   surveillance through intrusive gathering of protocol artefacts,
   including application content, or protocol metadata such as headers."

   "While PM is an attack, other forms of monitoring that might fit the
   definition of PM can be beneficial and not part of any attack, e.g.,
   network management functions monitor packets or flows and anti-spam
   mechanisms need to see mail message content"

He points out that sometimes monitoring is not an attack.

My take from RFC 7258 is that the key differentiator is user knowledge
and/or consent, i.e. if the user is not aware they are being monitored
and/or has not consented explicitly to altered data (in this case DNS
answers), that is what RFC 7258 considers an attack.

In the use case of DNS filtering, if the user is both aware of the
alteration of DNS answers (and why/how they might be altered) and has
consented via opt-in, that is a *service*, not an attack.

While there is not consensus in ADD/ABCD on the long term effectiveness
of DNS filtering as a control plane to enhance security, it is currently
a wide spread technique that much of the internet uses and finds value
with.

As Andrew said, we and the IAB should not be making blanket statements
that "all DNS filtering is wrong" as that doesn't correctly reflect all
of our stakeholders, considering the use case of user approved
filtering.

acampling> In my view it is unrealistic to expect that governments and
acampling> regulators will be content to allow the Internet's
acampling> infrastructure and those who run to be exempt from
acampling> cooperation with law enforcement activities, and totally
acampling> unregulated.  Indeed the many privacy, antitrust and other
acampling> issues that have surfaced relating to the tech sector over
acampling> the last several years have led to an environment where an
acampling> increase in oversight is both pretty much guaranteed and
acampling> necessary.

Agreed. Recent government panels in the UK and Australia on DoH and
concerns that this will break DNS filtering, even in cases where the
users wish to have it, shows that governments and law enforcement will
push back on technical standards. This is particularly likely if we
don't include them as stakeholders in discussions and help them
understand what these protocols do (and don't do).

This doesn't mean I'd advocate for government approval of IETF documents
but avoiding misunderstandings we can predict in advance does make it
less likely we'll be saddled with excessive and possibly ineffective
regulation.

acampling> It would be nice if we could understand better what is the
acampling> objective that the IAB wants to achieve with this statement
acampling> and what does it actually recommend, before commenting
acampling> further.

Agreed and something I'd love to see discussed next week. This is touchy
stuff and face to face discussions seem useful.