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

S Moonesamy <sm+ietf@elandsys.com> Sun, 17 November 2019 10:49 UTC

Return-Path: <sm@elandsys.com>
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 E059812007A for <architecture-discuss@ietfa.amsl.com>; Sun, 17 Nov 2019 02:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
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 HDrin218gFjd for <architecture-discuss@ietfa.amsl.com>; Sun, 17 Nov 2019 02:49:41 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A139F120059 for <architecture-discuss@ietf.org>; Sun, 17 Nov 2019 02:49:41 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.199.155]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAHAn6oI020749 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2019 02:49:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1573987777; x=1574074177; i=@elandsys.com; bh=EeWhzO1mWut5ZB9nyZvoSbSUzH9Sji7YEn4+dHgSOMY=; h=Date:To:From:Subject:In-Reply-To:References; b=dokXoXwAzBu4cZnd8XCdF/Qtm8iJBxuokR+NmRe7f74cq+aioQxqdH5sTvQuMEJ/D ct+T2jPuesR/AHjFQTMND/chjBLhdJW7ifeK+LOjl1z3GY2Jcc5FRQAOlmVwPATeKl J+QRjTx/T7odNhlLLJjpIvt6Li1dZDlY/+cM25LU=
Message-Id: <6.2.5.6.2.20191117022756.07532f60@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 17 Nov 2019 02:48:19 -0800
To: Andrew Campling <andrew.campling@419.consulting>, architecture-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760@LO2P265MB0573.GBRP2 65.PROD.OUTLOOK.COM>
References: <LO2P265MB0573C0D8F8D9D7ECF4E472AFC2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/gdIzkV25reJidVTfXvgrowpNi3I>
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: Sun, 17 Nov 2019 10:49:43 -0000

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

The position, in the past, was that it was important to preserve the 
chain of trust instead of allowing someone along the path to change 
the information published in DNS.  There are use cases where the 
changes are done for valid reasons, e.g. the user does not wish to 
download malware.  What are the unintended consequences of supporting 
such cases?

Regards,
S, Moonesamy