Re: [Doh] New Privacy Considerations Section Proposal

Adam Roach <adam@nostrum.com> Thu, 21 June 2018 19:42 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AB4130EC5 for <doh@ietfa.amsl.com>; Thu, 21 Jun 2018 12:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtXm4b4DTNmw for <doh@ietfa.amsl.com>; Thu, 21 Jun 2018 12:42:53 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AD0130DFA for <doh@ietf.org>; Thu, 21 Jun 2018 12:42:53 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5LJgneV070289 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Jun 2018 14:42:51 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Howard Chu <hyc@symas.com>, Patrick McManus <pmcmanus@mozilla.com>, Ted Hardie <ted.ietf@gmail.com>
Cc: DoH WG <doh@ietf.org>
References: <CAOdDvNpY4NpvSKW_D__jztDD_wkaRsJna9L+Br+hdnDnQ8w5SQ@mail.gmail.com> <CA+9kkMDt03Uv6UvtZw=mvo=+6dprGqUDMkC7Ef6bd=kb6vX_Fg@mail.gmail.com> <CAOdDvNrjZu-q63DUhNjf7fYjNux2ewv4DTZkGPvFRrGfBBJFMA@mail.gmail.com> <c67dc5cb-f6a5-4352-da59-71c4bb9ff98b@nostrum.com> <fc01b1ca-c0ca-88af-abf4-5fcfc1d954a3@symas.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <317567e1-9d3d-4981-e7a5-35c0b6557281@nostrum.com>
Date: Thu, 21 Jun 2018 14:42:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <fc01b1ca-c0ca-88af-abf4-5fcfc1d954a3@symas.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/FU7bhN6BVBCrL0fl6UC9ZqW5fFw>
Subject: Re: [Doh] New Privacy Considerations Section Proposal
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2018 19:42:55 -0000

On 6/21/18 6:22 AM, Howard Chu wrote:
> Adam Roach wrote:
>> [as an individual]
>>
>> I agree with Patrick's analysis here, and think the proposed text 
>> (plus the "minimal set of data" statement below) is likely to serve 
>> the purpose well. In particular, I agree with Patrick that the 
>> various features that have been cited so far each serve a useful 
>> purpose, and that such purposes may have a place in DoH deployments. 
>> Giving implementors a heads up about the privacy trade-offs seems 
>> appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal 
>> profile of HTTP seems to remove several of the advantages of using 
>> HTTP at all.
>
> That's overstating things. It seems the primary benefit is being able 
> to hide DoH traffic within standard HTTPS traffic, making it more 
> difficult to filter out at firewalls. That benefit remains, even if 
> barebones HTTP requests are used. 

Note that I didn't say "all" or "most" -- I said "several." If all we 
wanted was putting DNS requests over connections that are difficult to 
distinguish from ordinary HTTPS traffic, then we could have 
informatively described the use of HTTP CONNECT to set up RFC 7858 
connections and had a much simpler document.

/a