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

From: Eric Biggers <[email-masked]>
Date: Mon, 27 Apr 2026 16:20:54 -0700

On Mon, Apr 27, 2026 at 08:01:16PM +0000, Eric Biggers wrote:
> > - Ronald P. Bonica (the original RFC5925 author), together with Tony
> > Li do have an active RFC draft to support the additional algorithms
[...]
> > [1] https://www.ietf.org/archive/id/draft-bonica-tcpm-tcp-ao-algs-00.html

For what it's worth, that draft makes very little sense.  For example,
it proposes three variants of HMAC-SHA3, instead of just making the
modern choice of KMAC256.  And it proposes both HMAC-SHA384 and
HMAC-SHA512, despite them being redundant with each other after the
specified truncation to 128 bits.

Thus, it's clear that draft needs some work.  That would include, for
example, input from people who may be more familiar with best practices
for choosing cryptographic algorithms in new designs.

So I don't think the Linux kernel's implementation should, or needs to,
already implement all the algorithms in that unofficial draft.

All that's needed is the flexibility to add new algorithms later,
whether from a fixed version of that draft or from somewhere else.

We'll still have that with the library.

And to emphasize again, the current code also isn't really generic.  So
the support for new MACs doesn't necessarily come for free currently.
It probably works for arbitrary HMACs.  But HMAC != MAC.  If
AES-256-CMAC, BLAKE2, KMAC256, Poly1305-AES, or just about any other MAC
is ever needed, the code would have to be changed to support it anyway.

- Eric