From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 093F117B505 for ; Tue, 28 Apr 2026 05:42:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777354939; cv=none; b=fw32Xn4otDW+KzVpuG3Pg+2QXm71YiECQy1FN4mBUVBANbkLFtj1LbKt3071IX5/vLXU6jFK+eoQ2g0uEtrrsHHpffY38+lHksVlHKFo3H16EtJLmNsuutQkNiN/oVHxZzFpF2vmv1fjF6vf+lvL0/sNPhu7PWzjq1WvkFakDIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777354939; c=relaxed/simple; bh=qo5vRuAiZ5shJ6Ei1mLjY/jgzTrGIUBhYCvJ/yKzkJM=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=bM60vZcMBpwocIUgFtrSRMNOjVAa1Fur0IQNsvm771sjwCivlD0lmXdk2wHPlqGClcZ/r/W5T7J3QucHXDc83DSkYPi6E0KjGTgeUBAa0nNqZsU30yXtRQ/zv3hI5VWNeyypWgqdUWnZVhscshGphATntQQGq0/CSlUAWsJhveg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pAF5Y2Zi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pAF5Y2Zi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5759FC2BCB8; Tue, 28 Apr 2026 05:42:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777354938; bh=qo5vRuAiZ5shJ6Ei1mLjY/jgzTrGIUBhYCvJ/yKzkJM=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=pAF5Y2ZiBFhusXhH7EDhdTzjvuBK558DXMRdYLJWDGZ1gMQLuI2APCQbv88W490IT nd7r71KlSvWfAAhNCy0XuNhuCrdo0UWwvqecf1FiydQ4Tkc4Z3jc9GAwvqq0bPIkmP J0++PRPXCjAt52ngOzMpv1Ttqa2TXR3/wRiSsfKxtv0wwJroxPZau1gMhrLGDtr49G oukTHffUWhBlGE+tfw/OQX3QQ4IV54+3X+4jtR/KQl3omaSQtLh76vrejPekIryisp HEiQEjEzUMbTna24zt/vT4nYo8zsptBdJ0XS1AlZPxBn3VQnyB4gvNVNbD6laN4U/K EvZU8zP+oOQ1w== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 47211F40068; Tue, 28 Apr 2026 01:42:17 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Tue, 28 Apr 2026 01:42:17 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdektdejiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepfdetrhguuceu ihgvshhhvghuvhgvlhdfuceorghruggssehkvghrnhgvlhdrohhrgheqnecuggftrfgrth htvghrnhepvdeuheeitdevtdelkeduudetgffftdelteefteevjeevjeeiheefhfejieej fedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrugdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeijedthedttdejledq feefvdduieegudehqdgrrhgusgeppehkvghrnhgvlhdrohhrghesfihorhhkohhfrghrug drtghomhdpnhgspghrtghpthhtohepudeipdhmohguvgepshhmthhpohhuthdprhgtphht thhopeguihhmrgesrghrihhsthgrrdgtohhmpdhrtghpthhtohepuggrvhgvmhesuggrvh gvmhhlohhfthdrnhgvthdprhgtphhtthhopedtgiejfhegheegtgegieesghhmrghilhdr tghomhdprhgtphhtthhopehhvghrsggvrhhtsehgohhnughorhdrrghprghnrgdrohhrgh drrghupdhrtghpthhtohepvgguuhhmrgiivghtsehgohhoghhlvgdrtghomhdprhgtphht thhopehkuhhnihihuhesghhoohhglhgvrdgtohhmpdhrtghpthhtohepnhgtrghrugifvg hllhesghhoohhglhgvrdgtohhmpdhrtghpthhtohepughsrghhvghrnheskhgvrhhnvghl rdhorhhgpdhrtghpthhtohepvggsihhgghgvrhhssehkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 222A6700065; Tue, 28 Apr 2026 01:42:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: A-XTvJNalJ4N Date: Tue, 28 Apr 2026 07:41:56 +0200 From: "Ard Biesheuvel" To: "Dmitry Safonov" <0x7f454c46@gmail.com>, "Jakub Kicinski" Cc: "Eric Biggers" , netdev@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, "Eric Dumazet" , "Neal Cardwell" , "Kuniyuki Iwashima" , "David S . Miller" , "David Ahern" , "Paolo Abeni" , "Simon Horman" , "Jason A . Donenfeld" , "Herbert Xu" , "Dmitry Safonov" Message-Id: In-Reply-To: References: <20260427172727.9310-1-ebiggers@kernel.org> <20260427155538.2e1b8488@kernel.org> Subject: Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 28 Apr 2026, at 02:00, Dmitry Safonov wrote: > On Mon, 27 Apr 2026 at 23:55, Jakub Kicinski wrote: >> >> On Mon, 27 Apr 2026 20:09:05 +0100 Dmitry Safonov wrote: >> > I do like these numbers quite much! Yet, as I mentioned in version >> > 1, removing a fallback for other algorithms' support does not sound >> > good to me. There are two reasons: >> > - Ronald P. Bonica (the original RFC5925 author), together with >> > Tony Li do have an active RFC draft to support the additional >> > algorithms >> > [1], potentially in addition to TCP Extended Options [2] >> > - There is at least one open-source BGP implementation (BIRD) that >> > allows using the algorithms that you are removing [3]. Without a >> > deprecation period and communication with at least known open >> > source users, it implies intentionally breaking them, which I >> > can't agree with. >> > >> > I don't feel like Naking as we don't have any customers using >> > anything other than the 3 algorithms above (and BGP implementation >> > is [unfortunately] closed-source, so that would not feel >> > appropriate even if we had such customers), yet I do feel like it's >> > worth and appropriate to express my thoughts/concerns. >> >> What do you want to happen? You are the maintainer of this code, you >> don't get so say "i don't want to nack it but also no" :) > > Yeah, that's not what I meant. I see value in Eric's contribution, and > I like getting rid of tcp-sigpool. So, anything but "nack" is not "no" > :-) > >> Like Eric says if there are no real users code can be deleted. Adding >> deprecation warnings upstream is quite slow, IDK if injecting >> deprecation warnings to stable has been discussed.. > > FWIW, I've written to bird's mailing list inviting them to this > thread; in case if they need other algorithms to be supported, > hopefully that should avoid any breakages on their side. I'm aware > that ciena and fortinet use tcp-ao too, but I'm less concerned, as > they aren't open source. > Strongly agree with Eric here. We've been well aware for some time now that the LEGO brick model doesn't really work that well with crypto, and being able to combine arbitrary cryptographic primitives to construct your own algorithms from user space is not a feature, it's a bug. Sure, you can use HMAC to construct a MAC algorithm from any hash algorithm. But hashes are typically much more costly in terms of performance, due to the fact that they need to protect against collisions. MAC algorithms do not have this requirement, because they involve a secret key which is used symmetrically, i.e., both for signing and for authentication. IOW, forging a message to match a given MAC would require knowledge of the secret key, at which point an attacker can just use it to sign the message. This is the reason why more modern algorithms involving MACs use GHASH or Poly1305 instead (or KMAC256 as Eric suggested), which perform much better. Even AES-CMAC is not a great choice in this context. But these algorithms need to be constructed carefully, not just swapped in.