Re: [Add] [EXTERNAL] Re: Malware adopting DoH

"Ralf Weber" <dns@fl1ger.de> Fri, 13 September 2019 14:43 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 614BB12088D for <add@ietfa.amsl.com>; Fri, 13 Sep 2019 07:43:16 -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 uieTDmgX9fTs for <add@ietfa.amsl.com>; Fri, 13 Sep 2019 07:43:14 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id B1180120868 for <add@ietf.org>; Fri, 13 Sep 2019 07:43:13 -0700 (PDT)
Received: from [172.19.33.232] (unknown [23.79.228.15]) (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 7B5395F40440; Fri, 13 Sep 2019 16:43:11 +0200 (CEST)
From: Ralf Weber <dns@fl1ger.de>
To: Ted Lemon <mellon@fugue.com>
Cc: "Dixon, Hugh" <Hugh.Dixon=40sky.uk@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
Date: Fri, 13 Sep 2019 10:41:54 -0400
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <2B89D818-D42D-4EBA-96D1-6A9B55CA1097@fl1ger.de>
In-Reply-To: <ED3464BD-37A7-4B6F-8327-508B0CB76A3E@fugue.com>
References: <66DC417B-23BC-4AF7-916B-5BAE7E5D9635@sky.uk> <ED3464BD-37A7-4B6F-8327-508B0CB76A3E@fugue.com>
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/tS9_Qb4twW8PclxIN8iGjcFxUK0>
X-Mailman-Approved-At: Sat, 14 Sep 2019 08:41:59 -0700
Subject: Re: [Add] [EXTERNAL] Re: Malware adopting DoH
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: Fri, 13 Sep 2019 14:43:16 -0000

Moin!

On 12 Sep 2019, at 12:03, Ted Lemon wrote:

> A question you might ask is, “how do we know that this malware is 
> using DoH?”  Also, now that it is doing DoH, what new opportunities 
> exist for stopping it?  Is it easier or harder to trick it?
>
> It’s all very well and good to point out that it’s using DoH and 
> that this blocks certain mitigation strategies, but eg if Google can 
> mitigate it centrally we might be better off, not worse off, as a 
> whole.
I disagree. It would be nice if Google would mitigate these threats or 
follow local law when it comes to DNS answers. But having it all go to 
Google would still be centralisation with all the associated problems, 
which IMHO is a bigger problem.

The current name resolution architecture being de centralised with a lot 
of security happening in the edge is far better and we should try to 
keep that architecture and work on encrypting/securing the last missing 
pieces without changing the architecture.

We should also deploy public DoH services in a way that for security 
sensitive environments like enterprises it is possible to block them, so 
that these malware threats can not use them.

So long
-Ralf
—--
Ralf Weber