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

Paul Ebersman <> Wed, 13 November 2019 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0491A120807 for <>; Wed, 13 Nov 2019 14:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d4T7pgEYSMoJ for <>; Wed, 13 Nov 2019 14:29:31 -0800 (PST)
Received: from ( [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B183F120119 for <>; Wed, 13 Nov 2019 14:29:31 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6B5EB3740155; Wed, 13 Nov 2019 14:29:30 -0800 (PST)
Received: by (Postfix, from userid 501) id E72EC194CFA1; Wed, 13 Nov 2019 15:29:29 -0700 (MST)
Received: from fafnir.local (localhost []) by (Postfix) with ESMTP id E1B9F194CFA0; Wed, 13 Nov 2019 15:29:29 -0700 (MST)
From: Paul Ebersman <>
To: Andrew Campling <>
cc: "" <>
In-reply-to: <LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
References: <LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
Comments: In-reply-to Andrew Campling <> message dated "Wed, 13 Nov 2019 06:53:55 +0000."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <70824.1573684169.1@fafnir.local>
Date: Wed, 13 Nov 2019 15:29:29 -0700
Message-Id: <>
Archived-At: <>
Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 22:29:33 -0000

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

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

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

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.