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

[Eric Biggers]

On Tue, Apr 28, 2026 at 12:26:44PM -0400, Simo Sorce wrote:
> On Mon, 2026-04-27 at 16:20 -0700, Eric Biggers wrote:
> > 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.
> 
> Which is bogus in itself without proper security considerations, the
> only considerations cited is an RFC from 1997 ... clearly the pinnacle
> of cryptography advice ...
> 
> If they need a shorter hash they should make themselves a favor and use
> SHAKE and then define the desired output length and desired key size.
> That draft is just a disaster as written.
> 
> Specifically they should use KMAC128 as defined in NIST SP 800-185
> (which uses cSHAKE128 underneath).
> 
> Simo.

FWIW I left some feedback on the draft on on the tcpm mailing list
(https://mailarchive.ietf.org/arch/browse/tcpm/)

Another thing I should note is that the way TCP-AO uses HMAC-SHA1, it's
instantiated with an arbitrary-length key that might not contain full
entropy.  In contrast, the normal practice in cases like that is to do
an entropy extraction step first, e.g. see HKDF which has HKDF-Extract +
HKDF-Expand.

There's a chance this gets fixed in a future addition of HMAC-SHA256 or
whatever.  But in that case, the way the kernel happens to already
implement that algorithm (by assuming that it would be used in exactly
the same way as HMAC-SHA1) wouldn't match the eventual standard.

This is yet another reason why preemptively implementing "support" for
arbitrary algorithms wasn't a great choice...

 Eric