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

"Ralf Weber" <dns@fl1ger.de> Thu, 01 August 2019 18:36 UTC

Return-Path: <dns@fl1ger.de>
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 419671200E5 for <add@ietfa.amsl.com>; Thu, 1 Aug 2019 11:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 kNog_3W09hBe for <add@ietfa.amsl.com>; Thu, 1 Aug 2019 11:36:29 -0700 (PDT)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 01505120059 for <add@ietf.org>; Thu, 1 Aug 2019 11:36:29 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id AABBB5F42AC6; Thu, 1 Aug 2019 20:36:27 +0200 (CEST)
Received: from [192.168.2.128] (p54B8A0E0.dip0.t-ipconnect.de [84.184.160.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id C1DBF5F40409; Thu, 1 Aug 2019 20:36:26 +0200 (CEST)
From: Ralf Weber <dns@fl1ger.de>
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, Adam Roach <adam@nostrum.com>
Date: Thu, 01 Aug 2019 20:36:25 +0200
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <5BA9CB4E-D764-40F5-B2FA-86F319C13B90@fl1ger.de>
In-Reply-To: <a956c801f12745fb839f3a5394247002@cira.ca>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/hx298MBQcOTqMx52BL7OAs979bk>
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 18:36:31 -0000

Moin!

On 1 Aug 2019, at 19:59, Jacques Latour 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.
Interesting idea. I think that in addition to discovery mechanism for 
DoH servers we need some best practices rules for DoH server operators 
so that white hat operators of DoH servers don’t interfere with 
enterprise security and maybe a blacklist for those who use DoH for 
exfiltration. While the idea of the operators blocking requests from 
known enterprises is technically interesting I don’t think it fits 
into enterprise security requirements, as they want the packets not to 
leave their perimeter. So running DoH servers on know addresses (that 
some providers like Google already said they would do) and let the 
enterprise block them outbound might be the better way.

So long
-Ralf
—--
Ralf Weber