Re: [Doh] New I-D: draft-reid-doh-operator

Stephane Bortzmeyer <> Sun, 10 March 2019 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6017126DFA for <>; Sun, 10 Mar 2019 00:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PWXQG8rf8rVs for <>; Sun, 10 Mar 2019 00:02:15 -0800 (PST)
Received: from ( [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC772124B91 for <>; Sun, 10 Mar 2019 00:02:14 -0800 (PST)
Received: by (Postfix, from userid 10) id 3EEE8A052E; Sun, 10 Mar 2019 09:02:12 +0100 (CET)
Received: by godin (Postfix, from userid 1000) id B24E6EC0B0D; Sun, 10 Mar 2019 09:01:01 +0100 (CET)
Date: Sun, 10 Mar 2019 09:01:01 +0100
From: Stephane Bortzmeyer <>
To: Jim Reid <>
Cc: DoH WG <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 18.04 (bionic)
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
Subject: Re: [Doh] New I-D: draft-reid-doh-operator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Mar 2019 08:02:17 -0000

On Sun, Mar 10, 2019 at 03:29:51AM +0000,
 Jim Reid <> wrote 
 a message of 30 lines which said:

> FYI colleagues. The draft below has just been submitted. I've been given 10 minutes of WG agenda time at IETF104.

I'm surprised that it is published more or less at the same time
draft-livingood-doh-implementation-risks-issues. They have a lot of
overlap, and even one author in common. May be a merge would be a good

> When DoH is used, the customer will probably be dependent on DoH
> servers operated by third parties and have no contractual or
> business relationship with those providers.

Like draft-livingood-doh-implementation-risks-issues, there is a lot
of confusion between DoH-the-protocol and possible deployments of DNS
resolution via a public DNS resolver. The specific issue mentioned
above is exactly the same whether I use DoH or DNS-over-UDP to

[To be more precise: most of this draft is off-topic for the DoH
WG. If this is asked, I will say No to adoption by the WG.]

> Operators can also be required to perform DNS blocking and filtering
> or rewriting for legal reasons

Sure, but is it IETF's job to make it easier? RFC 2804 and 7754 would
be good references here.

> Typical regulations that could apply include General Data Protection
> Regulation (EU) 2016/679 [GDPR] and the EU-US Privacy Shield
> Framework [USPS]. [...] Logs containing individual DNS queries and
> the IP addresses or other data correlating those queries to specific
> users or homes may in some legal jurisdictions be considered as
> personally identifying information (PII).  In such jurisdictions
> detailed DNS query logs may be subject to data protection and
> retention regulations, or other legal and/or compliance
> requirements.

I'm very glad that people consider the importance of personal data
protection, and the useful role of the GDPR in it. But I fail to see
why it's specific to DoH. For *every* IETF protocol, the two parties
communicating may be in different countries (well, may be not for ND,
ARP and DHCP), and logging by one may infringe the laws of
another. Yet, we don't write drafts on the GDPR risks associated with
each specific protocol.

> Some list or registry of "trusted" DoH servers is probably
> necessary.

Why? I don't see it as necessary or unavoidable and even if it were,
why would it be IETF's business? Do we mention a "list of trusted AC"

> DoH has the potential to be more privacy intrusive than ECS, largely
> because DoH is based on HTTP and can leverage the rich per-user and
> per-device tracking that pervades the web today.  The implications
> of that are not yet well understood.