Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

Stephane Bortzmeyer <bortzmeyer@nic.fr> Thu, 09 January 2020 15:25 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FD5120100; Thu, 9 Jan 2020 07:25:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 QfahbET3Mm12; Thu, 9 Jan 2020 07:25:01 -0800 (PST)
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 7ED9512008D; Thu, 9 Jan 2020 07:25:01 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id BBCD828011B; Thu, 9 Jan 2020 16:24:59 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id B4DA8280154; Thu, 9 Jan 2020 16:24:59 +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 AD34628011B; Thu, 9 Jan 2020 16:24:59 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id A8DAF642C581; Thu, 9 Jan 2020 16:24:59 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 96EF23FDEE; Thu, 9 Jan 2020 16:24:59 +0100 (CET)
Date: Thu, 09 Jan 2020 16:24:59 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Sara Dickinson <sara@sinodun.com>
Cc: Martin Thomson <mt@lowentropy.net>, last-call@ietf.org, dns-privacy@ietf.org
Message-ID: <20200109152459.GA28511@nic.fr>
References: <4639bd67-6fca-47d1-aaeb-85fcd0394f46@www.fastmail.com> <029D8BB9-CE93-486A-BDF2-6D0720E59109@sinodun.com> <18c8c298-e462-490b-b3a3-5d5904d98c25@www.fastmail.com> <18F59166-83B9-4402-8703-B90589B540F5@sinodun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <18F59166-83B9-4402-8703-B90589B540F5@sinodun.com>
X-Operating-System: Debian GNU/Linux 10.2
X-Kernel: Linux 4.19.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.001392, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/a9TB8LeRGvu1Q4FMciAl9DIFVhY>
Subject: Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 15:25:03 -0000

On Tue, Jan 07, 2020 at 06:39:18PM +0000,
 Sara Dickinson <sara@sinodun.com> wrote 
 a message of 194 lines which said:

> > on the basis that it assumes that these optimizations are deployed
> > without regard to privacy.

May be just an informative reference to RFC 7231, specially section
9.7, would please everyone? This section seems quite comprehensive on
the issue of privacy leaks from HTTP headers.

> “the wide practice in HTTP to use various headers to optimize HTTP
> connections, functionality and behaviour which can introduce a
> trade-off between functionality and privacy

Most of the time, as noted by RFC 7231 in its section 3.4.1, the
privacy leaks bring no added functionality and no optimisation.