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

Jared Mauch <jared@puck.nether.net> Mon, 26 October 2020 20:05 UTC

Return-Path: <jared@puck.nether.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 BB6E93A0E9E for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 13:05:40 -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_PASS=-0.001, 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 8vhikvTAso8j for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 13:05:39 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB603A0E9B for <dnsop@ietf.org>; Mon, 26 Oct 2020 13:05:39 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id CEFB654014C; Mon, 26 Oct 2020 16:05:38 -0400 (EDT)
Date: Mon, 26 Oct 2020 16:05:38 -0400
From: Jared Mauch <jared@puck.nether.net>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Jared Mauch <jared@puck.nether.net>, Ted Lemon <mellon@fugue.com>, dnsop@ietf.org, kaduk@mit.edu
Message-ID: <20201026200538.GA1328776@puck.nether.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20201026174221.GC40654@faui48f.informatik.uni-erlangen.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ClMKum-CtQIe6cDQ2_pwF_7arxU>
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:05:41 -0000

On Mon, Oct 26, 2020 at 06:42:21PM +0100, Toerless Eckert wrote:
> Thanks, Jared
> 
> Somehow everybody tries to escape answering the question asked by giving
> their correct but orthogonal pet problem space answer. Ted correctly claims
> the protocols suck security wise, and you correctly claim that there are a lot more
> deployment considerations in face of risky underlays.
> 
> At this point in time i am just trying to get an RFC out the door, and Bens
> security review was asking for options how to operationalize the choosen protocol
> to be hardened. My answer was the heuristic.
> 
> If the anwer of the experts is "do not harden implementations of existing protocols",
> but only improve protocols or eliminate security risks from underlays, i think
> that is not a good strategy to show to implementors trying to understand how
> to best harden existing protocols, but i will happily take that guidance
> and remove the text about the suggested heuristics.

	I think we often forget several things about the security aspects
of devices, like physical access == root (for example), on-link or on-network
attackers will always have an advantage available to them.

	Things like mDNS are only as secure as their local link, and if an attacker
is on-link there are risks that can be controlled for and those that can't.

	We have had problems elsewhere as md5/tcp-md5 provide engouh mutual peer
authentication to be of value, but can be broken with a persistent on-link or
on-path attacker.

	I was also just providing examples of other protocols (dhcp, ra) that
share the same on-link risks.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.