[tcpm] Re: draft-ietf-tcpm-tcp-ao-algs-05 early Secdir review

[Eric Biggers <[e-mail]>]

On Tue, Jul 21, 2026 at 07:21:34PM +0000, Bonica, Ron wrote:
> Regarding the second issue, HMAC-SHA256 satisfies the requirement. When TCP-AO uses HMAC-SHA256, it consumes 36 of the 40 option bytes available in the TCP headers. So, TCP support for HMAC-SHA256 will require extended TCP options.

HMAC-SHA256 with the full, untruncated 256-bit MAC, that is?  Do you
know what's driving the perceived need for such long MACs?

> Since we will have extended the TCP option field already, is there a reason why we shouldn't skip ahead to HMAC-SHA384 or HMAC-SHA512. Is the increased computational cost significant?

Currently, on most CPUs SHA-256 (and SHA-224 which is the same speed as
SHA-256) is significantly faster than SHA-512 (and SHA-384 which is the
same speed as SHA-512).  Notably, x86_64 accelerates SHA-256 but not
SHA-512.  arm64 accelerates both, but the SHA-256 acceleration works
much better.

However, better SHA-512 acceleration might appear.  (E.g., Intel
recently put it in client CPUs, but not server CPUs for some reason.)
And from what I've heard TCP-AO performance isn't too critical anyway?

If you want to choose SHA-512 (instead of SHA-256) I am fine with that.
But we should be clear about what we would be getting out of it.  It
might satisfy a request from people who prefer it due to the perceived
higher internal strength.  Maybe that's a good enough reason, so that
another option doesn't need to pop up later.  But I do not think it
would actually benefit security or performance.

- Eric