Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00

Michael Sinatra <michael@brokendns.net> Tue, 16 July 2019 17:36 UTC

Return-Path: <michael@brokendns.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4712B120ACF for <add@ietfa.amsl.com>; Tue, 16 Jul 2019 10:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 r040Zhd8XhDM for <add@ietfa.amsl.com>; Tue, 16 Jul 2019 10:36:19 -0700 (PDT)
Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (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 96804120A6D for <add@ietf.org>; Tue, 16 Jul 2019 10:36:19 -0700 (PDT)
Received: from elwha.brokendns.net (elwha.brokendns.net [IPv6:2607:f2f8:a544:0:0:0:0:2]) by burnttofu.net (8.15.2/8.15.2) with ESMTPS id x6GHaDBI045021 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 16 Jul 2019 13:36:15 -0400 (EDT) (envelope-from michael@brokendns.net)
Received: from Michaels-MacBook-Pro.local (50-197-156-42-static.hfc.comcastbusiness.net [50.197.156.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id DAFA45D95B; Tue, 16 Jul 2019 10:36:12 -0700 (PDT)
To: Jim Reid <jim@rfc1035.com>
Cc: add@ietf.org
References: <CAChr6SwEUz9MrdRA0bnv9f-oNi0oUHkfRKjd9-o6jwhuckLXdw@mail.gmail.com> <CAFWeb9LNdT=EYVKTsYDxcBCQKoQFNShKotYtWujt4U9GA-V1mg@mail.gmail.com> <CAFWeb9+eWKSKY9O2JLn9-0+Zq7hrD48F-y+Y4T-iRaaF0vtdOA@mail.gmail.com> <A45F4F74-D6C1-435A-A52F-C2DEA82E2999@sky.uk> <CAFWeb9JVBj+Yehup5q4v9X-7XDY+02frd-04AQGL2HoSLON2qA@mail.gmail.com> <CABcZeBMY9q9vKGse1svzbvXF_dSHA+9q06j4ugDVCZP9VT1koQ@mail.gmail.com> <CAChr6Sz5Rfz=UxOYuPguSvVK2HCX2ZoA1-FytW7+EOUxN8y46Q@mail.gmail.com> <CABcZeBNB7ASu2U3ZMBZ+OOxEhbSnhDXwFN3Lsex1uzVSDv3R=Q@mail.gmail.com> <c9c83673-c12e-0093-3873-0f2c03155fa5@brokendns.net> <53A70CFB-4191-41F9-A33E-047E0F092B66@rfc1035.com>
From: Michael Sinatra <michael@brokendns.net>
Message-ID: <6cde4bf8-3a64-62fe-cd79-e8af7f2bedb4@brokendns.net>
Date: Tue, 16 Jul 2019 10:36:12 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <53A70CFB-4191-41F9-A33E-047E0F092B66@rfc1035.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [IPv6:2607:fc50:1:9d00:0:0:0:9977]); Tue, 16 Jul 2019 13:36:18 -0400 (EDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/JQmDbAlf8y3FxKC8UH2hzW01Zlc>
Subject: Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 17:36:21 -0000

On 7/16/19 10:25 AM, Jim Reid wrote:
> 
> 
>> On 16 Jul 2019, at 17:33, Michael Sinatra <michael@brokendns.net> wrote:
>>
>> Unless we find ways of making DoH compatible with institutional controls, the banhammer will come down and we will end up in an arguably worse spot (think proxy decryption of all HTTPS, banning of certain browsers, blocking of well-known services, etc.).  Personally, I don't want that to happen, but I fear it will if we don't make DoH more flexible by default.
> 
> Obligatory nit-picking:
> 
> What you're actually talking about here is one deployment/application of DoH, not the protocol itself. The basic protocol is fine (pretty much). It's how the protocol gets used that can create problems. DoH doesn't have to or need to become "compatible with institutional controls". It's the applications and services which use DoH might have to do that.
> 
> FWIW, I agree with what you say if "DoH" was replaced with "DoH deployment".
Yes, everything I am talking about in this thread is as you say--my 
intent was "DoH deployment" even though I only said "DoH."  Thanks for 
the opportunity to clarify.

The one disagreement I have with DoH as a protocol is that it 
essentially obfuscates the DNS resolution process, from a network 
perspective.  But that's not under discussion here (and it's basically 
water under the bridge anyway).

michael