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

Ben Campbell <> Thu, 28 September 2017 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C53F133011; Wed, 27 Sep 2017 20:31:13 -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 6tzw1mWIeYun; Wed, 27 Sep 2017 20:31:11 -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 B9E9F132D67; Wed, 27 Sep 2017 20:31:11 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v8S3VAtH015040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Sep 2017 22:31:11 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_CB073685-B36B-4910-A750-CF79F5CDA8CE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 27 Sep 2017 22:31:09 -0500
In-Reply-To: <>
Cc: The IESG <>,,
To: Adam Roach <>
References: <> <>
X-Mailer: Apple Mail (2.3273)
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:31:13 -0000

> On Sep 27, 2017, at 10:20 PM, Adam Roach <> wrote:
> 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.

I should let Terry speak for himself, but I thought at some point he mentioned that as the reasoning DPRIVE was not interested. I may misremember.

Don’t get me wrong, I’m happy enough with this going forward. This was a “yes” ballot.  I just wanted to make sure we hadn't changed the basic premise which generated the “not in DPRIVE” decision.

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

Yeah, I think that was entry number 86 :-)

> /a