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

Ted Lemon <mellon@fugue.com> Sun, 25 October 2020 19:41 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 CEAE93A158F for <dnsop@ietfa.amsl.com>; Sun, 25 Oct 2020 12:41:32 -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, MIME_QP_LONG_LINE=0.001, NO_DNS_FOR_FROM=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 tADIVmz9IC2F for <dnsop@ietfa.amsl.com>; Sun, 25 Oct 2020 12:41:30 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 AE2283A1102 for <dnsop@ietf.org>; Sun, 25 Oct 2020 12:41:30 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id g13so3352689qvu.1 for <dnsop@ietf.org>; Sun, 25 Oct 2020 12:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=7z6FXjTfzcdlKX8pHkzWgZjAJEn6YLVf0YIKQtq8BZk=; b=zwW70V60j0dznlWD6qsWX28vSJYMqGfD4vfgAeEwLWrQdrRiaz7iiUrbUZsbZO9Q9E v2NRTEZ/riHM5vY/PNxq2jv55teTiIkdhe3jkbdeQwgnF/U9IIewQxo61AK4VIkVS8VL tFU7r8MhaxN+NPeRTC1xaD2taz9lCZxS+r31EvnbEoCgHoBVdgqqQkwrWF1YUyhN5iPH vB5ghWLYmCx5QZZcqTaaH0DvwxE7oWhph9z3omD9zzQb9vkQzF2ZlWjJbeO9bbFY1zgS rbq9BL3O0tAkA7WckVj/qJ/Ulgnz9zB8clYsRsPQ5VA5wjqWOPgzig3PPJpoDUeOZ8D7 oVWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=7z6FXjTfzcdlKX8pHkzWgZjAJEn6YLVf0YIKQtq8BZk=; b=C/T2tZ2Daj6k9lwBE15gpXZ6l18dcM6YcpL88gEFjOEFm29Vax0XOv/5ZWT3/sf7s6 GgOR/51J8aojivAiK6QKI4G50IJsgqdhcZogZgenGFCOtRTN0OMJjEXr9cIbHRWHtKJD F6M3yHMtAkJK9eGRU6HZ7kpdkMpjI1XHoRCG9UEaUuE7fLKBBdkzK08Or4yyr/q95AxW QIXguJA711PKKS5/lCDLKsI/IxPoY/Zf32BOXosJaGhtkMgkpxFOWYJseeQRjV6H7/Tx oRzr0RdjeK1ODFXiTnhxJsZcsDTUfxDOLn/POklqiU5NPSs69k377R5gmARxqg3uwz33 n3Xg==
X-Gm-Message-State: AOAM531KcjakQPW89DcOpmtmHXOBpCS26Cvb6KUZdUpiFbA6DyEDg/4e oE1eacWYyAdHmrRW6c52VBzL/xXzDoaXfQ==
X-Google-Smtp-Source: ABdhPJx/ET6MLZW49epb6ObRk6HVYfSYwEhcrwwz5Oq5qatz3Zw8Z6Cupm4ZIFTJyJUDUzg8E0pRhg==
X-Received: by 2002:a0c:aa8f:: with SMTP id f15mr8478780qvb.46.1603654889032; Sun, 25 Oct 2020 12:41:29 -0700 (PDT)
Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id i20sm3339063qtw.66.2020.10.25.12.41.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Oct 2020 12:41:28 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 25 Oct 2020 15:41:26 -0400
Message-Id: <539093D8-97C4-448F-A9C4-288C2586BC51@fugue.com>
References: <20201025192456.GG48111@faui48f.informatik.uni-erlangen.de>
Cc: dnsop@ietf.org, kaduk@mit.edu
In-Reply-To: <20201025192456.GG48111@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: iPhone Mail (18B79)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4FX0gLM4_Puop7Ntj-8Ofvh-qmQ>
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: Sun, 25 Oct 2020 19:41:33 -0000

That would be a very bad heuristic. The whole point of SRV records is to eliminate the dependency on reserve ports. 

Really this is a non problem. We are not seeing this on home networks at present, because it’s just not an interesting attack. But supposing that we wanted to do something about it, the way to do so would be twofold. 

First, use protocols that allow for establishment of trust so that an on link spammer’s offered service can’t mimic a trusted service. E.g., use self signed certs and TOFU to prevent spoofing. 

Second, switch away from Multicast to DNSSD over DNS, and establish trust that way. If services register using DNSSD Service Registration Protocol, FCFS naming prevents spoofing of trusted services. 

Of course there always has to be a trust establishment process, like BRSKI. 

I’m sure that something similar can be done with anima. 

> On Oct 25, 2020, at 15:25, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> Ben Kaduk (SEC AD) was wondering about the appropriateness of a hardening suggestion
> in draft-ietf-anima-autonomic-control-plane-29. Let me translate this into
> mDNS, even though its about GRASP, but IMHO for the purpose of this issue
> its equivalent:
> 
> Node wants to discover on a LAN a particular service and unfortunately, attackers
> on the LAN want to spam it.  For example by sending out a significant number
> of false mDNS messages claiming the service is available on a variety of 
> of ports (lets keep attacks against other serive parts like the I address
> out of this). And in effect, the node will attempt a lot of service instantiations
> to bogus ports.
> 
> Now, in one case, the service may have an IANA registered well-known TCP or UDP
> port number. So the hardening recommendation in our draft text is that if a lot
> of answers are received AND the node knows that there is a well-known port, then
> it should prioritize trying the service over that well known port.
> 
> Any reason why this would not be a good obvious heuristic ?
> Has this been considered for mDNS alreay anywhere (rfc ?).
> 
> Of course, if there is no well known port, this does not help. And if
> the non-attacker can only offer a service with a well-known port number only
> on a non-well-known port number, than it actually hurts, but i think those
> are unavoidable limitations. And it easily spells out that one of the
> key benefits of getting a well-known port number for something is to
> be able to avoid having to guess in the face of such attacks, when discovery
> of port number can not be secured.
> 
> Aka: In our case we have one potential upcoming service over DTLS, and
> this text could help decide later on if we wanted to apply for a
> well-known port number for this service if we get operational experience
> that that could help in conjunction with this hardening recommendation.
> 
> Cheers
>    Toerless
> 
> P.S.: for original text in subject draft look for "Attackers on a subnet may be able to inject malicious"
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop