Re: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT)

Adam Roach <> Thu, 28 September 2017 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E77513528A; Wed, 27 Sep 2017 20:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id omJq10B-dBkO; Wed, 27 Sep 2017 20:20:13 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9726135271; Wed, 27 Sep 2017 20:20:13 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v8S3KB3h013002 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Sep 2017 22:20:12 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be Orochi.local
To: Ben Campbell <>, The IESG <>
References: <>
From: Adam Roach <>
Message-ID: <>
Date: Wed, 27 Sep 2017 22:20:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Sep 2017 03:20:15 -0000

On 9/27/17 22:06, Ben Campbell wrote:
> I'm balloting "yes", but I have a point of confusion on the following text:
> "The primary focus of this working group is to develop a mechanism that
> provides confidentiality and connectivity between DNS Clients and Iterative
> Resolvers.  While access to DNS-over-HTTPS servers from JavaScript running in
> a typical web browser is not the primary use case for this work, precluding
> the ability to do so would require additional preventative design. The working
> group will not engage in such preventative design."
> I remember someone (Terry, maybe?) stating earlier that the justification for
> keeping this separate from DPRIVE was that confidentiality was_not_  the
> primary use case, and connection from JS in browsers_was_.

I seem to recall that the issue with doing it in DPRIVE was that DPRIVE 
made it clear that they were not interested. I thought Terry said as 
much during the last formal telechat, although the narrative minutes 
don't seem to capture it in a way that matches my memory.

The conversation about the charter so far -- like the input document -- 
are based primarily on "getting queries through networks where they 
might otherwise be blocked, snooped, or tamped with" as the primary use 
case, and the javascript-in-a-browser use case as secondary. There was 
one proponent on who was specifically interested in the 
latter case, but the language above that precludes blocking that ability 
should serve those purposes fine.

> I see where people
> decided otherwise in the (95 entries so far) discussion thread--but does that
> change the relationship with DPRIVE? Especially since the first sentence comes
> directly from the DPRIVE charter?

I took the line from DPRIVE because it was already vetted. :)

You can find context for that specific addition here: