From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 8A05320CB2 for ; Fri, 22 Mar 2024 01:36:48 +0100 (CET) Received: (qmail 3648 invoked by uid 550); 22 Mar 2024 00:32:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3606 invoked from network); 22 Mar 2024 00:32:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711067796; x=1711672596; darn=lists.openwall.com; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ekAX9gvItV+azbwuuY7qO5IfE/1LPmp+HvHgDFTRh4I=; b=fQUrdN3f5v7UbqGQfqFo07ToIY44REflFenZnoLhT670vqo7bV2fWq0/DWsT5+XJ3e HRIWCZsAmBpfsjuTi8vFu3zZYwmbwPKeYmbRLvBA1zmnJI/PibjC7fiY/exjWCFy9e9E e5AbVaujwVOO166QNWJErQ9lupp/M1CYTS1zX+el1aAXHkksD+ECmkFVysT0HszssKs3 jLSgCeBeiBkAp25snaP8a/X1WvyUr75c6ZVGD27s8ZnS+/xuVvzEChs0ptjSFM+aXTea 1oTKONhuQ+GKcoymS0NSlvIZ68Y4Rc3asFJf0k1sn56nmmlpTV9enGN5UT1jnNs90Ok3 eyBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711067796; x=1711672596; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ekAX9gvItV+azbwuuY7qO5IfE/1LPmp+HvHgDFTRh4I=; b=RHJLjHjnsU0t7O3lhm870dMjieAIBMsiF5AredqZdntHqhqXtlDXsmsUsuSU0oyFI2 d2/aXlvpTjfKsEDrKArIDbzpSag+RNT5Kfz/L0+erL712+Ef1WRv97KwwWdHLNTcN/pt kEBV2jLSgqnh3w1B+We4+/+A7qNqFRAZ5GOc9vqEDIpF0wz3MsWIdRp4F+lssCVJLMOp WJoAlNkH4ZzUZB44e2NjaA8KegLSv3MmGwep3g6yTRej/bIpUdQEB/gKn09ZX80/idoo I6PpfRDPlE+yQqEYZJ/qTkBd2Qg3mjJOM+KMHx8znhMZYNOZs7WgsFII9TGu0Zod8iZK vZGg== X-Gm-Message-State: AOJu0YxGWfYlbP4+QCLTSb+o5I7ra1DXSwqm/ZC32auvnVCpfK3Buy1A PVJRON/llMsf73A4c/O/TGhAfTEaD5+w4qlCF4+9TVpZcRW9Wpm97ZWGk4D3NGp72YD7/G1u2bK rw5N3yV7OCBht1GbCBzek5bqdxaDd5z6hJF4i9Q== X-Google-Smtp-Source: AGHT+IFRpvtzkAxveJP86UhVzfZ/sk4umfVlT5gpD1f16qxaJzS0ESlPRHNi4PneoEL6gj7PB39hvahfp3JgjXWvEbA= X-Received: by 2002:a17:906:2dd5:b0:a44:e371:a31b with SMTP id h21-20020a1709062dd500b00a44e371a31bmr617919eji.10.1711067795830; Thu, 21 Mar 2024 17:36:35 -0700 (PDT) MIME-Version: 1.0 References: <20240308203143.GQ4163@brightrain.aerifal.cx> <20240308225445.GR4163@brightrain.aerifal.cx> <20240321120727.GI15722@brightrain.aerifal.cx> <20240321193552.GO4163@brightrain.aerifal.cx> In-Reply-To: From: David Schinazi Date: Fri, 22 Mar 2024 10:36:24 +1000 Message-ID: To: musl@lists.openwall.com, Rich Felker Content-Type: multipart/alternative; boundary="000000000000283eb3061435047a" Subject: Re: [musl] mDNS in musl --000000000000283eb3061435047a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From an ability to respond to the query, you're absolutely right. Sending all your DNS queries to multicast would be a bad idea. But this is specific to .local, where any use of .local is aware of the fact that it is sent unprotected over multicast and plans accordingly at the application layer. David On Fri, Mar 22, 2024 at 10:31=E2=80=AFAM Tomas Volf <~@wolfsden.cz> wrote: > On 2024-03-22 10:10:29 +1000, David Schinazi wrote: > > > PS: which are the stakeholders contacted while the relevant standards > > > brought in such hazardous default? > > > > > > These RFCs went through the IETF Standards Track process, so the entire > > IETF community was consulted when this was finalized around 2011-2012. > > > > I'd like to understand why you think this is hazardous though. mDNS onl= y > > applies to host names under .local - those names are not covered by > DNSSEC, > > and therefore any queries for them are always sent completely insecure. > > Sending those queries over the wire to the configured DNS resolver has > very > > similar security properties to sending them over the wire as multicast. > > Please ignore my comment from the peanut gallery if it is totally off, bu= t > is it > not a difference between being able to do MitM (for regular non-DNSSEC > DNS) and > just being on the same network (multicast)? So the former only > router/gateway > can do, the latter anyone able to respond to the multicast? Assuming my > understanding is correct, that does not seem "very similar security > properties". > > Have a nice day, > Tomas Volf > > -- > There are only two hard things in Computer Science: > cache invalidation, naming things and off-by-one errors. > --000000000000283eb3061435047a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From an ability to respond to the query, you're absolu= tely right. Sending all your DNS queries to multicast would be a bad idea. = But this is specific to .local, where any use of .local is aware of the fac= t that it is sent unprotected over multicast and plans accordingly=C2=A0at = the application layer.
David

=
On Fri, Mar 22, 2024 at 10:31=E2=80= =AFAM Tomas Volf <~@wolfsden.cz> w= rote:
On 2024-03= -22 10:10:29 +1000, David Schinazi wrote:
> > PS: which are the stakeholders contacted while the relevant stand= ards
> > brought in such hazardous default?
>
>
> These RFCs went through the IETF Standards Track process, so the entir= e
> IETF community was consulted when this was finalized around 2011-2012.=
>
> I'd like to understand why you think this is hazardous though. mDN= S only
> applies to host names under .local - those names are not covered by DN= SSEC,
> and therefore any queries for them are always sent completely insecure= .
> Sending those queries over the wire to the configured DNS resolver has= very
> similar security properties to sending them over the wire as multicast= .

Please ignore my comment from the peanut gallery if it is totally off, but = is it
not a difference between being able to do MitM (for regular non-DNSSEC DNS)= and
just being on the same network (multicast)?=C2=A0 So the former only router= /gateway
can do, the latter anyone able to respond to the multicast?=C2=A0 Assuming = my
understanding is correct, that does not seem "very similar security pr= operties".

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
--000000000000283eb3061435047a--