Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

Michael Sinatra <michael@brokendns.net> Tue, 12 March 2019 20:29 UTC

Return-Path: <michael@brokendns.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46638128B14; Tue, 12 Mar 2019 13:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sr2v886Qd2zo; Tue, 12 Mar 2019 13:29:40 -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 D61A1127817; Tue, 12 Mar 2019 13:29:39 -0700 (PDT)
Received: from elwha.brokendns.net (elwha.brokendns.net [206.125.172.202]) by burnttofu.net (8.15.2/8.15.2) with ESMTPS id x2CKTW28061687 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 12 Mar 2019 16:29:34 -0400 (EDT) (envelope-from michael@brokendns.net)
Received: from nofx.lbl.gov (nofx.lbl.gov [IPv6:2620:83:8000:107::f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id 2502465A00; Tue, 12 Mar 2019 13:29:34 -0700 (PDT)
To: Jim Reid <jim@rfc1035.com>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: dnsop WG <dnsop@ietf.org>, DoH WG <doh@ietf.org>, dns-privacy@ietf.org
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net> <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com> <20190312153636.qdsdne24vmi4xdoe@nic.fr> <50BAF399-B95D-438B-B3FC-05A0159439E2@noware.co.uk> <20190312160141.ibnjtdt5myntwiwk@nic.fr> <D63B07FA-508A-42CC-833E-BAC2B4E7BD91@rfc1035.com>
From: Michael Sinatra <michael@brokendns.net>
Message-ID: <096d59ee-0524-833f-f421-dbb05ce9b2b8@brokendns.net>
Date: Tue, 12 Mar 2019 13:29:30 -0700
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: <D63B07FA-508A-42CC-833E-BAC2B4E7BD91@rfc1035.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [162.217.113.18]); Tue, 12 Mar 2019 16:29:37 -0400 (EDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zUM_vD1krRuHYh6Ya8Gqf1ZSjg4>
Subject: Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 20:29:41 -0000


On 3/12/19 9:14 AM, Jim Reid wrote:
> 
> 
>> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>>
>> I still do not understand why people have a problem with DoH whch did
>> not already exist before with my-own-name-resolution-protocol-over-HTTPS.
> 
> It’s a question of scale/ubiquity. These “alterate” resolution tricks have up until now been mostly confined to a small number of clueful people. That is going to change dramatically once the world’s web browsers and other web-based apps start using DoH. More so if those platforms have DoH enabled by default.

There's also a fundamental tension that arises when we define as
legitimate those practices that are indistinguishable (or hard to
distinguish) from what bad guys do.  Think of all of the HR departments
out there that send *legitimate* emails asking their employees to click
on a link to update/verify information.  DoH does this too and it
arguably goes a step further by effectively obfuscating DNS resolution
activity, so that legitimate users occupy the same "hideout" as the bad
guys.

This is one of the main themes of section 9 of draft-reid-doh-operator
and one of the main motivations in the recommendations of section 4 of
draft-bertola-bcp-doh-clients, but it bears restating because for those
of us trying to do risk mitigation, or even policy compliance, DoH gives
us additional headaches.

michael