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

Jim Reid <> Sun, 10 March 2019 12:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C72E51295EC for <>; Sun, 10 Mar 2019 05:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0LNZ6fm4qfCk for <>; Sun, 10 Mar 2019 05:54:32 -0700 (PDT)
Received: from ( [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0530012D84C for <>; Sun, 10 Mar 2019 05:54:32 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id AF4DA242109D; Sun, 10 Mar 2019 12:54:23 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <>
In-Reply-To: <>
Date: Sun, 10 Mar 2019 12:54:18 +0000
Cc: DoH WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Stephane Bortzmeyer <>
X-Mailer: Apple Mail (2.3445.9.1)
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 12:54:36 -0000

On 10 Mar 2019, at 08:01, Stephane Bortzmeyer <> wrote:
>> 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.

The draft is not asking the IETF to do that Stephane. And it's a *huge* mistake to make that assumption. All the I-D is doing here is documenting one of the issues that will arise in operator networks once DoH is widely deployed. There are other issues. As the draft explains.

Personally speaking I think on DNS blocking and filtering, the train left the station a long, long time ago. It isn't coming back and the IETF is highly unlikely to define a protocol for DNS blocking and filtering. That doesn't mean it isn't an issue in certain environments. Or that widespread uptake of DoH is going to complicate matters for those who do have to do these things.

> 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.

Well, this is the DoH WG. Where else should we consider the role of GDPR for that protocol and its usage? ;-) GDPR is a huge, sprawling issue that cannot possibly be addressed in one over-arching framework for esch IETF protocol. So IMO it's best to approach that on a procotol-by-protpcol (or WG-by-WG) basis. YMMV.