Re: [Doh] New: draft-livingood-doh-implementation-risks-issues

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 12 March 2019 15:16 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AFE131000 for <doh@ietfa.amsl.com>; Tue, 12 Mar 2019 08:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 qImb3nKhaeLb for <doh@ietfa.amsl.com>; Tue, 12 Mar 2019 08:16:41 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C04130FC4 for <doh@ietf.org>; Tue, 12 Mar 2019 08:16:41 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 714F428011C; Tue, 12 Mar 2019 16:16:39 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 6B47E28038C; Tue, 12 Mar 2019 16:16:39 +0100 (CET)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 631DA28011C; Tue, 12 Mar 2019 16:16:39 +0100 (CET)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 5CC50663E080; Tue, 12 Mar 2019 16:16:39 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 5542640235; Tue, 12 Mar 2019 16:16:39 +0100 (CET)
Date: Tue, 12 Mar 2019 16:16:39 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, DoH WG <doh@ietf.org>
Message-ID: <20190312151639.oqgwgdficezoygfr@nic.fr>
References: <EA2A119D-06CF-4B0B-8994-86A99CD8AC0B@cable.comcast.com> <20190309182857.GA29321@laperouse.bortzmeyer.org> <BAB74C4B-D93A-4EBA-8F76-FEC4C68FF753@cable.comcast.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BAB74C4B-D93A-4EBA-8F76-FEC4C68FF753@cable.comcast.com>
X-Operating-System: Debian GNU/Linux 9.8
X-Kernel: Linux 4.9.0-8-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.107364, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.3.12.150616
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/ap2fegODCnTHzJjThCvSAOD2qJs>
Subject: Re: [Doh] New: draft-livingood-doh-implementation-risks-issues
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 15:16:42 -0000

On Mon, Mar 11, 2019 at 01:49:31AM +0000,
 Livingood, Jason <Jason_Livingood@comcast.com> wrote 
 a message of 64 lines which said:

> But I certainly think you can concede generally speaking that
> networks (of all types) strive to maximize performance &
> reliability, and this usually includes good DNS services.

I certainly hope it is the case. But not all the things I hope for
materialize.

>  >  > Loss of Parental Controls or other Content Controls

> Many people have young children and may want to filter what content
> they have access to at home.

And some have children and never deployed any sort of technical
parental control. (Or not using the DNS.)

It seems to me there is a more profound issue here: should we (the
IETF), when creating new protocols, ensure that *all* previous usages
continue to work? Even if we never condoned them?

Replying Yes to this question would put a severe burden on IETF
shoulders; there are so many "creative" uses of the TCP/IP
technologies that it is impossible to guarantee that everything will
continue to work as before. Creating new protocols or new variants of
old protocols will certainly disrupt things. Is it always bad? I don't
think so.