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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC3E112788C; Tue, 12 Mar 2019 20:20:33 -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 V-PlrZu5DuAT; Tue, 12 Mar 2019 20:20:30 -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 5997112705F; Tue, 12 Mar 2019 20:20:30 -0700 (PDT)
X-One-Unified-MailScanner-Watermark: 1553052027.76065@ME98ZMqiOvwR1z6WPnYVqg
X-One-Unified-MailScanner: Not scanned:
X-One-Unified-MailScanner-ID: x2D3KMsH015420
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 x2D3KMsH015420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2019 03:20:23 GMT
To: Ted Hardie <>, Paul Vixie <>
Cc: dnsop <>, DoH WG <>
References: <> <3457266.o2ixm6i3xM@linux-9daj> <> <1914607.BasjITR8KA@linux-9daj> <>
From: Raymond Burkholder <>
Organization: One Unified Net Limited
Message-ID: <>
Date: Tue, 12 Mar 2019 21:20:22 -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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Doh] [DNSOP] 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: Wed, 13 Mar 2019 03:20:34 -0000

On 2019-03-12 2:52 p.m., Ted Hardie wrote:

> the feasibility of this migration.  We also acknowledge that many 
> network operations activities today, from traffic management and 
> intrusion detection to spam prevention and policy enforcement, assume 
> access to cleartext payload.  For many of these activities there are no 
> solutions yet, but the IAB will work with those affected to foster 
> development of new approaches for these activities which allow us to 
> move to an Internet where traffic is confidential by default.

So... would someone be able to identify some of the 'new approaches' 
which help security practitioners ply their trade?

If these approaches were identified, then perhaps there would be less 
resistance to maintaining access to the cleartext flows we use to 
maintain security state.

> by default.  You have been working around that, rather than developing 
> new practices.  I invite you instead to consider how you can accomplish 
> what you need to in an Internet where all traffic is confidential.  

Can some of these new practices be part of the protocol development process?

> Enterprises are currently doing that via managed software and 
> environments, and that approach seems to be well in-line with your 
> practices below.  Using resolution systems for this will not accomplish 

Where can I read up on some of these practices?

> what you need now, nor will it do so going forward; it is time for a 
> different approach, rather than seeking to return to cleartext.
> The situation that moved this community to that stance was well-laid out 
> in IETF 88.  We must acknowledge that not all devices which are on-path 
> are controlled by entities known to the user or network operator and not 
> all of them are acting in the interests of those parties.  Protecting 
> against that threat requires us to change our ways.  Please help, rather 
> than working around the effort.