[tcpm] Re: draft-ietf-tcpm-tcp-ao-algs

[Eric Biggers <[e-mail]>]

On Tue, May 05, 2026 at 01:42:12PM +0000, Bonica, Ron wrote:
> John,
> 
> My apologies for the typo. It was hasty cutting and pasting.
> 
> At this point, I am looking for consensus. Is the WG OK with the following algorithms:
> 
> KDF_KMAC256
> MAC-KMAC256-128
> 
> KDF-HMAC-SHA256
> MAC-HMAC-SHA256-128
> 
> If not, could we reach a compromise by adding a third option:
> 
> KDF_KMAC256
> MAC-KMAC256-128
> 
> KDF-HMAC-SHA256
> MAC-HMAC-SHA256-128
> 
> KDF_AES_256_CMAC
> MAC-AES-256-CMAC-128

The fewer algorithms, the better.  The more there are, the more costly
it will be for TCP-AO implementers, and the more interoperability
failures there will be.

AES-256-CMAC would have implementation advantages in the near term: it
would be similar to the existing AES-128-CMAC, and AES hardware
acceleration is already widespread.

However, I'd also be quite happy with KMAC256 as a more forward-looking
option which avoids the 128-bit block size limit and is faster when
implemented in hardware.  In the long term, it should work better.
Keccak hardware acceleration is becoming more widespread, in part due to
its use in the "post-quantum" algorithms ML-DSA and ML-KEM.

So yes, I'm on board with KMAC256.  If there's also demand for a more
incremental upgrade to one of the existing algorithms, let's choose
either HMAC-SHA256 *or* AES-256-CMAC as a second new algorithm, not
both.  Probably HMAC-SHA256.  (And yes, in both cases, the MAC would
have to be truncated to 128 bits to fit in the TCP options space.)

- Eric