Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"
Paul Ebersman <list-architecture-discuss@dragon.net> Wed, 13 November 2019 22:29 UTC
Return-Path: <list-architecture-discuss@dragon.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0491A120807 for <architecture-discuss@ietfa.amsl.com>; Wed, 13 Nov 2019 14:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4T7pgEYSMoJ for <architecture-discuss@ietfa.amsl.com>; Wed, 13 Nov 2019 14:29:31 -0800 (PST)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B183F120119 for <architecture-discuss@ietf.org>; Wed, 13 Nov 2019 14:29:31 -0800 (PST)
Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 6B5EB3740155; Wed, 13 Nov 2019 14:29:30 -0800 (PST)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id E72EC194CFA1; Wed, 13 Nov 2019 15:29:29 -0700 (MST)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id E1B9F194CFA0; Wed, 13 Nov 2019 15:29:29 -0700 (MST)
From: Paul Ebersman <list-architecture-discuss@dragon.net>
To: Andrew Campling <andrew.campling@419.consulting>
cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
In-reply-to: <LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
References: <LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
Comments: In-reply-to Andrew Campling <andrew.campling@419.consulting> 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: <20191113222929.E72EC194CFA1@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/vypEcV0_eipFE2QAwqnyV8LDZfk>
Subject: Re: [arch-d] IAB statement on "Avoiding Unintended Harm to Internet Infrastructure"
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=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 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.
- [arch-d] IAB statement on "Avoiding Unintended Ha… Vittorio Bertola
- Re: [arch-d] IAB statement on "Avoiding Unintende… Andrew Campling
- Re: [arch-d] IAB statement on "Avoiding Unintende… Paul Ebersman
- Re: [arch-d] IAB statement on "Avoiding Unintende… Mark Nottingham
- Re: [arch-d] IAB statement on "Avoiding Unintende… Stephen Farrell
- Re: [arch-d] IAB statement on "Avoiding Unintende… Paul Ebersman
- Re: [arch-d] IAB statement on "Avoiding Unintende… Brian Trammell (IETF)
- Re: [arch-d] IAB statement on "Avoiding Unintende… S Moonesamy
- Re: [arch-d] IAB statement on "Avoiding Unintende… Brian Trammell (IETF)