Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library

["Ard Biesheuvel" <ardb@kernel.org>]

On Tue, 28 Apr 2026, at 02:00, Dmitry Safonov wrote:
> On Mon, 27 Apr 2026 at 23:55, Jakub Kicinski <kuba@kernel.org> 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.