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=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 E0FC2242C3 for ; Fri, 22 Mar 2024 01:31:26 +0100 (CET) Received: (qmail 24161 invoked by uid 550); 22 Mar 2024 00:26:50 -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 20434 invoked from network); 22 Mar 2024 00:25:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1711067384; bh=aaQlO7RaA1mDjCnQ/WmT1gJo9CCfa7ejdVd7c/XY1Xs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=wjdYPypeN2zUUcJ8uRR2K9osBbzsiGtRIgE+yiIftQWI2K6kA7/DZLsEjBb4Hyh9P qbW7UvNMV5ViioQ2RCzAuvNby3T/rr9W2sUweYpwgTVxgXF0Z/eoVyUtKdL51IJorn qoMyn1zSp0RUBdozHzcPqy/E2vrUv0LNl20deihBifIFqvwIpL8FjuBkwx22SzKQEo tDc4pusU4sHnkWBqfXBUXCnOwLzz2C0zXfUY4Dm8XXUn7QnDtunVMLBMwS0o8ifZNz 9YR/LPuemOXRca4coqFMBROlV5hwwlspLa2/EA+aI43xS2O8VU61T9iZiH4FkAFXuY ZA8BmknSxQpLac+2pjcKf68kRoNhGrRFQzOjA0zxW3I7n5ymVuah6qjscT0d7olS8+ QJOXVwpr3M4IRQBcQXNH+jY43eR38bO3IqKRWSuhRWve88RmpEUxSIqMa3ItM+65K5 0SuI2q4ELFLPrCuJzh/fMEX1a51S5/Jb44S4QAx+WsGEE7Y5nLWpUKkEthJQr49ePx Q7FWiO6TQSN3O3QNjOBQIhY1rG8EY3XVobvDJSLph7daQHVAEIL20TL7pYhK5Uw2Jh OcsiEZJjcwZMsTyqM+GYT5UfdYP9guPGEjcV22DeyUUUdus8qJR8keTmrzaKw7wONB TUfHMqcpgIQ57WUQjuihabmw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wolfsden.cz; s=mail; t=1711067384; bh=aaQlO7RaA1mDjCnQ/WmT1gJo9CCfa7ejdVd7c/XY1Xs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=wjdYPypeN2zUUcJ8uRR2K9osBbzsiGtRIgE+yiIftQWI2K6kA7/DZLsEjBb4Hyh9P qbW7UvNMV5ViioQ2RCzAuvNby3T/rr9W2sUweYpwgTVxgXF0Z/eoVyUtKdL51IJorn qoMyn1zSp0RUBdozHzcPqy/E2vrUv0LNl20deihBifIFqvwIpL8FjuBkwx22SzKQEo tDc4pusU4sHnkWBqfXBUXCnOwLzz2C0zXfUY4Dm8XXUn7QnDtunVMLBMwS0o8ifZNz 9YR/LPuemOXRca4coqFMBROlV5hwwlspLa2/EA+aI43xS2O8VU61T9iZiH4FkAFXuY ZA8BmknSxQpLac+2pjcKf68kRoNhGrRFQzOjA0zxW3I7n5ymVuah6qjscT0d7olS8+ QJOXVwpr3M4IRQBcQXNH+jY43eR38bO3IqKRWSuhRWve88RmpEUxSIqMa3ItM+65K5 0SuI2q4ELFLPrCuJzh/fMEX1a51S5/Jb44S4QAx+WsGEE7Y5nLWpUKkEthJQr49ePx Q7FWiO6TQSN3O3QNjOBQIhY1rG8EY3XVobvDJSLph7daQHVAEIL20TL7pYhK5Uw2Jh OcsiEZJjcwZMsTyqM+GYT5UfdYP9guPGEjcV22DeyUUUdus8qJR8keTmrzaKw7wONB TUfHMqcpgIQ57WUQjuihabmw= Date: Fri, 22 Mar 2024 01:29:43 +0100 From: Tomas Volf <~@wolfsden.cz> To: musl@lists.openwall.com Cc: Rich Felker Message-ID: Mail-Followup-To: musl@lists.openwall.com, Rich Felker References: <20240308203143.GQ4163@brightrain.aerifal.cx> <20240308225445.GR4163@brightrain.aerifal.cx> <20240321120727.GI15722@brightrain.aerifal.cx> <20240321193552.GO4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Dbfm9SmTs89BzBYj" Content-Disposition: inline In-Reply-To: Subject: Re: [musl] mDNS in musl --Dbfm9SmTs89BzBYj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 only > 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, 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)? 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. --Dbfm9SmTs89BzBYj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmX80PcACgkQL7/ufbZ/ wanT/A/+LkeERH9CG/46Es7yXwWUFcp+qI1o6P+QpWaE4hN2XBdHNser6Gojy4yA W1cZ4M5ctrsVS78RGjMraowBDyMO6MFmXm0yLOxCxL3vz+1/U9Mjj5W6Gca7aKsu 7E+0KdjO8CEF09sjYT6UE2GA1SGCZVy2VRnx9lwx2akL1SPjMR45DYS9DZNS4EOT atk91t9E31L0hcE1ZvjVi5zdGkOcKpGRtQsW+W8/CJSLMMTt3pUk2wgA9cyMMWlj OvoIJhOANF07czRbMabdP8j53JOGsN+9nXDdlWS+jk1EfsU+uXtOACD9a9MRAOKG e/TArdNtcaIkUoXuwzQTt9bsfyLrG2JLSxGQ1J3OB7SDdm/5ueKGSYSV7rb0p9tu CNWzxNjrYbsgnp9sDN7x33m/aIy7vhyW0Vnh65CtNARpQaS4WT37LU1jsbblGMmc eYte1u/yLyeYSRhF0TvbqANTs7wzT5e8QeZSQJX96d+BLBJA7puUdkHB9F4c+9Rd RiP++hzcrNijuRvtrOS/mhLY9eKUioAhgTfh002pAvQp7dLAlGL7ZLp61ip/HpZk 9y/wCkuYwe01UdrDnkXHXHbi6kpXmhlukRYIz3+ruh9zMdmvpclbsIMZ0KLXgFsR 0m1Xiqqzdm87u8IG7tAA/evqr3LYRekX4Fm+ZWOfQYUKKwqwioY= =oMbq -----END PGP SIGNATURE----- --Dbfm9SmTs89BzBYj--