Re: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks

Ted Lemon <mellon@fugue.com> Mon, 26 October 2020 20:39 UTC

Return-Path: <mellon@fugue.com>
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 29BD23A0EEE for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 13:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 e4hmmW527GbQ for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 13:39:13 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 7EBD13A0EE9 for <dnsop@ietf.org>; Mon, 26 Oct 2020 13:39:13 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id q199so9705521qke.10 for <dnsop@ietf.org>; Mon, 26 Oct 2020 13:39:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YjSDRUJMS0VNoA9NxlM3Rw+LlP4ojUIkaOLWiNdyMcQ=; b=w7zkbfl1EHTAHGnmQm9txhFrBNJw3jUNPUJH/PNsdnB9Ta+AfhUJtxUDMdC/lwEa6s qsXw833EfaVoBMV+DUw0YaYXkVdwWWpi1kVmyrL/m4pssjvre3P5k2QiQOh/SIjdhcxf 4w42baDVyy6vQvfevWL2Yq5ZuB//6PGVxUvQ21RRIjMvHK4UJWGHyHx81mBoYwuO5xZt PBkjFt08IgNGujY4HB6fAb60RbdUPzlD7HkvuJ6O26Mr9i2dTLXoL6neiUwiVQ62ZQmd Ntkuyx1CdyrtjNsMBaIN0PdRroeJRG1MNB520xNwOjVtu3KPkZS7Rz8Pb7n3FCrBZLU+ /oOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YjSDRUJMS0VNoA9NxlM3Rw+LlP4ojUIkaOLWiNdyMcQ=; b=fbaoRvO2QUkRe6x7RBDSSSjMBI//t8KYmP38QxXUWFeuW0q7FVa8JDXZeykIRuFnj4 ueKQGIVv99612vYXTa+t0Y9w2UHBu/cehcCPpt40ebqrpmX/eFKRm03B1u8/0mx70SDF 7dKqcdm3JkeLe9FrLH8/NchXeih6tDErOyreN69EiREhFDZStHUy5wYDKEG8BW6mmUi1 gjxn7dH5nDf4f3xOmKzGQ3akhWBYaeme50L0673RBQJBaYwlEyOONogKuB929pvSBKgn MDAkrgCZXiSWx35zRLGJMya1QNcCWUbcwQKl3hKlKjVaEpMcL2h8wEWupMWNPqTrKbh1 L1Cw==
X-Gm-Message-State: AOAM533Pgu0kD9nteAmSWzwdkcYIaLv7JJuYkTm3iLeaUEvvU2n4K754 l6RgTP0qRoOlspfohSYepRVivg==
X-Google-Smtp-Source: ABdhPJyGhnoGDV4SKvwe99qvscOeObMZEZ4iz4r/W/RQ3HJeiDItGe1CuWvJBVUOsVJ5qhSgrBFnDA==
X-Received: by 2002:a37:686:: with SMTP id 128mr18011205qkg.421.1603744752225; Mon, 26 Oct 2020 13:39:12 -0700 (PDT)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id j8sm7425267qke.38.2020.10.26.13.39.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2020 13:39:11 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <20201026201448.GD40654@faui48f.informatik.uni-erlangen.de>
Date: Mon, 26 Oct 2020 16:39:10 -0400
Cc: Jared Mauch <jared@puck.nether.net>, dnsop <dnsop@ietf.org>, kaduk@mit.edu
Content-Transfer-Encoding: quoted-printable
Message-Id: <84D39283-D696-476E-A9CB-2ACCD7A7365F@fugue.com>
References: <20201025192456.GG48111@faui48f.informatik.uni-erlangen.de> <539093D8-97C4-448F-A9C4-288C2586BC51@fugue.com> <20201026165915.GA40654@faui48f.informatik.uni-erlangen.de> <41920477-8979-49EC-9F14-11A100D622FF@fugue.com> <6D931ED7-7A34-4E9D-B2CC-D2F555D79E0B@puck.nether.net> <20201026174221.GC40654@faui48f.informatik.uni-erlangen.de> <20201026200538.GA1328776@puck.nether.net> <4EBB9789-EDA8-418F-898F-3A2D0B3C5CC2@fugue.com> <20201026201448.GD40654@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3654.0.3.2.91)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8UbYhb_le4emnvLGhFR5v3v_J2M>
Subject: Re: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks
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: Mon, 26 Oct 2020 20:39:15 -0000

On Oct 26, 2020, at 4:14 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> And the question from the AD was what could be done. So, do you have any
> implemention suggestion ? Are there any sugestions for mDNS ?

There are no simple mitigations. If there were, they would already be in the protocol.

> Btw: I do agree that for most use of mDNS as it is relying on dynamic ports,
> my suggestion would create an undesired trend of allocating static port numbers.
> This is also true for GRASP in general, but for the specific use-cases
> in mind in my text, which are really inside-network infra protocols, the argument could be
> made that static port allocation was indeed well feasible (as we're talking about a
> very small number here) . But we had not done it because we hadn't vetted the benefits
> of doing such a port allocation.

If it’s a multicast discovery protocol with no authentication, then constraining the set of allowed ports just means that the node that’s attacking you has to be able to listen on that port, which it likely can. So I think this reduces function without increasing hardening.

What actually hardens mDNS is that it’s a link-local protocol. It doesn’t work across links. This limits the attack surface. But there’s no way to eliminate the attack surface.  If I were in Ben’s shoes, I’d be asking you to change the protocol to support authentication and ToFU as a hardening strategy, with some better trust establishment mechanism as future work based on the existing presence of crypto signatures. But the current consensus of the IETF is apparently that ADs aren’t allowed to insist on things like that. :(