Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

Raymond Burkholder <> Wed, 13 March 2019 02:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CABB1277DB; Tue, 12 Mar 2019 19:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q0cJWkHxD0S5; Tue, 12 Mar 2019 19:20:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4269112716C; Tue, 12 Mar 2019 19:20:53 -0700 (PDT)
X-One-Unified-MailScanner-Watermark: 1553048446.86058@7dkIhg02GGVo+6hDntueFg
X-One-Unified-MailScanner: Not scanned:
X-One-Unified-MailScanner-ID: x2D2KhpI014706
X-OneUnified-MailScanner-Information: Please contact the ISP for more information
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4) with ESMTP id x2D2KhpI014706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2019 02:20:44 GMT
To: Paul Vixie <>,
Cc: "" <>, "" <>, Christian Huitema <>, Stephen Farrell <>
References: <> <2356055.DoC3vY7yXE@linux-9daj> <> <7128698.bmqQpDD1M4@linux-9daj>
From: Raymond Burkholder <>
Organization: One Unified Net Limited
Message-ID: <>
Date: Tue, 12 Mar 2019 20:20:42 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <7128698.bmqQpDD1M4@linux-9daj>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
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: Wed, 13 Mar 2019 02:20:56 -0000

On 2019-03-12 4:51 p.m., Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> DoH intends "to prevent on-path interference with DNS operations", and that's
> well beyond the remit of RFC 7626, and is therefore not spoken to one way or
> another by IETF consensus. i do not believe that a non-interference objective
> would reach broader IETF consensus. perhaps we can test that one day.

I'm not sure I understand the double-double negative happening here.

It appears to me that there is considerable support for DoH, meaning 
there is support for non-interference.

In the IPv6 spectrum with the mac/slaac randomization games which have 
become standardized, and which have been instituted to supply other 
forms of security/hiding/non-interference, it appears that DoH would 
similarly be 'allowed' through the standardization process.

Having said that, and if this is how one performs the testing, I would 
have to say that DoH would be make it much harder for me as a security 
engineer to perform my duties.

It would seem that if DoH is standardized, then it would probably become 
standard practice, then like and similar quads, by default 
meaningful data becomes hidden for managing the interior of networks.

For some networks, pi-hole is a mechanism for preventing certain traffic 
operations.  AS I look at it this moment, it has over 112K domains 
blacklisted, and on one particular network, 31% of the queries have been 
blocked as a passive protection mechanism.

I find these blocks useful.  With DoH, probably DoH would become 
ubiquitous, and these types of blocks would be prevented.

Https is common ground for much hiding.  DNS is probably our last 
bastion of having any semblance of identification of what is happneing 
to the interior of our networks.  Carriers might not be so concerned. 
But for those who operation enterprise, business, home, some forms of 
social protection, security management becomes more difficult.

As has happened in the IPv6 space, the same happens here in the DNS 
space: there are groups who wish the privacy/non-interference/hiding 
ability vs the groups who need the information in the data streams to 
properly secure and manage the interior and perimeter.

How would the requirements of each group be recognized?  The simplest 
would be to not proceed with DoH.