From nobody Sun Oct 25 12:41:34 2020 Return-Path: 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 ; 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 ; 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 ; Sun, 25 Oct 2020 12:41:30 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id g13so3352689qvu.1 for ; 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 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 X-Mailer: iPhone Mail (18B79) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 eli= minate the dependency on reserve ports.=20 Really this is a non problem. We are not seeing this on home networks at pre= sent, because it=E2=80=99s just not an interesting attack. But supposing tha= t we wanted to do something about it, the way to do so would be twofold.=20 First, use protocols that allow for establishment of trust so that an on lin= k spammer=E2=80=99s offered service can=E2=80=99t mimic a trusted service. E= .g., use self signed certs and TOFU to prevent spoofing.=20 Second, switch away from Multicast to DNSSD over DNS, and establish trust th= at way. If services register using DNSSD Service Registration Protocol, FCFS= naming prevents spoofing of trusted services.=20 Of course there always has to be a trust establishment process, like BRSKI.=20= I=E2=80=99m sure that something similar can be done with anima.=20 > On Oct 25, 2020, at 15:25, Toerless Eckert wrote: >=20 > =EF=BB=BFBen Kaduk (SEC AD) was wondering about the appropriateness of a h= ardening 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: >=20 > Node wants to discover on a LAN a particular service and unfortunately, at= tackers > on the LAN want to spam it. For example by sending out a significant numb= er > of false mDNS messages claiming the service is available on a variety of=20= > 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 instan= tiations > to bogus ports. >=20 > Now, in one case, the service may have an IANA registered well-known TCP o= r 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. >=20 > Any reason why this would not be a good obvious heuristic ? > Has this been considered for mDNS alreay anywhere (rfc ?). >=20 > 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 on= ly > 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 discove= ry > of port number can not be secured. >=20 > 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. >=20 > Cheers > Toerless >=20 > P.S.: for original text in subject draft look for "Attackers on a subnet m= ay be able to inject malicious" >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop