Re: [Add] [EXT] Re: meeting hum: should the IETF take up this work?

Eric Orth <ericorth@google.com> Thu, 01 August 2019 20:49 UTC

Return-Path: <ericorth@google.com>
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 5CC6F12022B for <add@ietfa.amsl.com>; Thu, 1 Aug 2019 13:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 sF0iZWvPl6k9 for <add@ietfa.amsl.com>; Thu, 1 Aug 2019 13:49:44 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 11CED1201EA for <add@ietf.org>; Thu, 1 Aug 2019 13:49:44 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id y4so74984227wrm.2 for <add@ietf.org>; Thu, 01 Aug 2019 13:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ReDs22nvjoDmnvNEy3DwIy6+MGQzJmFAjoyeOqMYFoY=; b=kMRCmtIhlJbR3xeQQcuWT/ONziimolNaSJyrhgUyca3PToTHYf3UVkxmLcvnCFcXTm tvqHpslrV7rD+B1ENwkSScDq5FrPHv+7YCFPBJxl5iaMirVFTMqTnghKmIPhxx1ej+ps ilLJQqA2cbIKxOg9iz1r2CzKf31C9XVq7qClFtdTYf9odVNRd63BqArm+4qVUOOU1+4h uTezNVudLXkK4XO0jmB3Ag8X6csvYlzrJqHg4zcL5yoen1F9PDhm5GxV6ZjW+vlYprkA Fr+x2CD1UqbaNmYrbV5sLTkv16Civ6LdBXv0uxngvRswl9gzw4JVu8DY9q21fqm4wugO XCcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ReDs22nvjoDmnvNEy3DwIy6+MGQzJmFAjoyeOqMYFoY=; b=Z3uk7EzFZ7zyG+l0Ej6CApKUxq6I63evZH/SjIHub3u7y6ZDMokA5v6yJd7s+91WtE aL5NCu0eYv91JvIhfTC8vI4j9AAwHgOGtsZvINwtGYLAItQ4uFtUKBWpzkz3Z3/at1s8 WuE3OTL7tNZCYU4FXq02vZ8mHbUd6Kp8BlxXV16phHmVbDANdUe3r1L4LZBbGxdMmI1x RmCWqoA5OYIZPbS6ocqp+ktJQ6N+7GDA3BSClq9sKOWJ6ql5W3j4/dpFFCYZcxvs15T6 js0pwp+kh29YcH07czNfsAmhrkXDcu2h0ioNeIZ2SST3NAm0tG/6Lk+kLNFWN9HBU5Tm xdeA==
X-Gm-Message-State: APjAAAWAckdG8JXlHoOiCg0BCu5PzkVG9CbtLJRE6UZS8byOPmj+5Mag waMIhCIwVWqVY1TdLt5ywYo/yM0mzRPRaOGKzQIVDA==
X-Google-Smtp-Source: APXvYqzR/8uHhT246ZOVe4QTz2N8oKHVuIVSEQdXhvAZt+v5klWWLZ5FdS9UMCacQpDGE15UJhyN18Th2w1GJHp1ous=
X-Received: by 2002:adf:d081:: with SMTP id y1mr1275183wrh.34.1564692582134; Thu, 01 Aug 2019 13:49:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <AAEA003A-58DB-4FEE-81B2-BBFE9BBB2A37@rfc1035.com> <CAChr6SwA+HM4u5-xpUxQXPH8G8k7sfm6AETJJ019HE=bsq+OXA@mail.gmail.com> <8F094057-DFBC-4732-9DA4-BE46E7914C8A@rfc1035.com> <20190724165951.GB29051@laperouse.bortzmeyer.org> <821B448B-F7EA-46A5-837D-DA0E8C60643A@open-xchange.com> <d653d422-4a71-9fab-fd2e-b8ddaa476f91@nostrum.com> <488E2CE0-73D5-4B9E-A5AD-28FDCB95ED2A@cable.comcast.com> <CAN6NTqyAzZY5TG8Y7ks0zEMdVuE=+m1JC0n3Dn5_1c6EKgBwwA@mail.gmail.com> <a956c801f12745fb839f3a5394247002@cira.ca>
In-Reply-To: <a956c801f12745fb839f3a5394247002@cira.ca>
From: Eric Orth <ericorth@google.com>
Date: Thu, 01 Aug 2019 16:49:29 -0400
Message-ID: <CAMOjQcHkiNF8QE7zo3X9Xd6RvzwE=rfqMckOf37KmT-3U2M=Xw@mail.gmail.com>
To: Jacques Latour <Jacques.Latour@cira.ca>
Cc: Ólafur Guðmundsson <olafur=40cloudflare.com@dmarc.ietf.org>, "Livingood, Jason" <Jason_Livingood@comcast.com>, "add@ietf.org" <add@ietf.org>, Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="0000000000008abe47058f146194"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/N3JCDPByTre9kWm2vxUK0y4aNEY>
Subject: Re: [Add] [EXT] Re: meeting hum: should the IETF take up this work?
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: Thu, 01 Aug 2019 20:49:46 -0000

On Thu, Aug 1, 2019 at 1:59 PM Jacques Latour <Jacques.Latour@cira.ca>
wrote:

> From the department of this-could-be-a-bad-idea and the department of
> omg-this-goes-against-everything-we’re-trying-do, but here it goes: a DoH
> operator should have a policy to blacklist IP address as requested by the
> network operator, since we can’t effectively block DoH at the edge of the
> enterprise network, an enterprise network should have the ability to
> request the well behaved DoH recursive operators to block requests coming
> from their network IP address.  Perhaps have some sort of trusted clearing
> house of IP addresses that the well behaved DoH recursive operators should
> blacklist from. Enterprises can block non well behaving DoH recursive
> operators.
>
>
>
> Since the major problems of DoH is for all to understand the
> multidimensional matrix of deployment models vs. value proposition vs. user
> (vantage) point of view, it’s almost impossible to assess the value
> proposition of the above example against all the currently
> possible/available scenarios. But we know that DoH has a negative value
> proposition for Enterprises.
>
>
>
> How do we turn DoH to have a positive value proposition for Enterprise?
>
>
>
> Can DoH have positive value proposition for all scenarios?
>
>
>
> What are the gaps and how do we address them methodically?
>
>
>
> Jack
>
>
>

I can't speak for any DoH server operators, but I would imagine most would
not be willing to trust a please-block-these-IPs/names signal unless the
agent sending the signal could prove it has authority over the user/device
making the request.  Could be very damaging for an enterprise's operations
if an unauthorized attacker can disrupt their access to websites the
enterprise wants to be able to access.  Maybe there's a way I'm missing,
but I'm having trouble thinking of any way for the blocking agent to prove
that authority without having control of the requesting user/device.  And
if any enterprise has that control, they should be able to just block
IPs/names from the device or control from there what DNS server is used.