From owner-freebsd-security@freebsd.org Sun Sep 12 22:10:46 2021 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6932466F3EE for ; Sun, 12 Sep 2021 22:10:46 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "submission.mff.cuni.cz", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H73hj2Mmjz4sr7 for ; Sun, 12 Sep 2021 22:10:44 +0000 (UTC) (envelope-from dan@obluda.cz) X-SubmittedBy: id dan@mff.cuni.cz subject /postalCode=110+2000/O=Univerzita+20Karlova/street=Ovocn+5CxC3+5CxBD+20trh+20560/5/ST=Praha, +20Hlavn+5CxC3+5CxAD+20m+5CxC4+5Cx9Bsto/L=Praha+201/C=CZ/CN=Dan+20Luke+5CxC5+5CxA1/emailAddress=dan@mff.cuni.cz serial CD205F9D3D7CB4A48FB4D309D9790FA2 issued by /C=NL/O=GEANT+20Vereniging/CN=GEANT+20Personal+20CA+204 auth type TLS.CUNI DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obluda.cz; s=mffsubmission; t=1631484635; x=1632784635; bh=qxpoRGY52oWGI2DVDr8BXWvbDSfVjRfhCR+8wik8C3c=; h=From:MIME-Version; b=NBLFtUM2fchni2xzRpKwD5YGpM7kBZtoPOJ88fOZlT27L57FCKHYfEYfD1Kx5L1hv MgFEA46ZZCNACbSr6GdBWagFtmM/Zs6eI8CYfDuUC9GsZ76ajgx7FYJsEocVNtaQJL M/xQDjHUbFi/4akyIa1HyDjG1ZXAeTgEB/RJtd+A6FbS3eNAu3LlyaF6SGpWjOQYW2 8B1+eFt3QTfw3j3Qo9Dqc7GlFpzwop21MoKRf6h4hu6EBnhgQ/35FyvVb4KJ4OLe8K 7k8YEd4Aj5cLyYc6fEd16Qf0zyQHDeBkQFaRXRkz24YX9MIYm0jznu7ptrrarcYTyu Ld20goEo5Jjvw== Received: from [10.46.29.2] ([194.108.204.138]) (authenticated) by smtp1.ms.mff.cuni.cz (8.16.1/8.16.1) with ESMTPS id 18CMAWCl058766 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Mon, 13 Sep 2021 00:10:34 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: Important note for future FreeBSD base system OpenSSH update To: freebsd-security References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> From: Dan Lukes Message-ID: <0c3a5f3c-fb07-fae3-22f3-28703c842deb@obluda.cz> Date: Mon, 13 Sep 2021 00:10:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.9 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4H73hj2Mmjz4sr7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obluda.cz header.s=mffsubmission header.b=NBLFtUM2; dmarc=pass (policy=none) header.from=obluda.cz; spf=none (mx1.freebsd.org: domain of dan@obluda.cz has no SPF policy when checking 2001:718:1e03:801::4) smtp.mailfrom=dan@obluda.cz X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[obluda.cz:s=mffsubmission]; FREEFALL_USER(0.00)[dan]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[obluda.cz:+]; DMARC_POLICY_ALLOW(-0.50)[obluda.cz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2852, ipnet:2001:718::/32, country:CZ]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 22:10:46 -0000 On 12.9.2021 23:27, Gordon Tetlow via freebsd-security wrote: > Blaming the browser and other client providers (OpenSSH, etc) for a=20 > problem that is 100% because the devices are now abandoned by the=20 > manufacturer is the wrong place to focus your anger. We have an=20 > enormous problem in the industry of crappy embedded devices (like the=20 > OOB management plane) accruing technical security debt while the=20 > manufacturers give "a middle finger back" as you say. The=20 > supportability of the hardware needs to be baked into the purchasing=20 > decision. Commitments from the manufacturers on supportability=20 > timeframes are important to understand and budget into a hardware=20 > refresh cycle. "One size fits all" may be acceptable approach for unskilled home users, = but not for professional use. The security mechanism may be secure=20 enough for particular use even if there are known issues with the method = in question. There may be a various reason to abandon particular method/algorithm but = don't claim it's for my security because it's just not true. If=20 particular algorithm is not secure enough for me I'm not using it=20 despite it's supported. If algorithm is the best for particular case=20 (it's why I'm using it) the removal will decrease overall security of=20 such system.=A0 In no case the security will be increased. We should avoid to make decisions on behalf of skilled security officer=20 familiar with particular use case. Just my $0,02 Dan