[tcpm] Re: Feedback on draft-ietf-tcpm-tcp-ao-algs-00

["Bonica, Ron" <[e-mail]>]

Eric,

Thanks for the review. I suspect that we will trim the list of proposed algorithms. Version-00 of the draft was just a starting point.

You say:

"I suggest simplifying the proposal to just HMAC-SHA256 for now.  That's the only one that seems like an obvious choice.  Indeed, SHA-256 is the usual replacement for the outdated SHA-1."

Do you mean HMAC-SHA256-128? Or do you really mean HMAC-SHA256?

I propose HMAC-SHA256 in draft-bonica-tcpm-tcp-ao-long-algs<https://datatracker.ietf.org/doc/draft-bonica-tcpm-tcp-ao-long-algs/>. But if we go there, we need to solve the problem identified in TCP Extended Options<https://datatracker.ietf.org/doc/draft-bonica-tcpm-extended-options/>.

                                                                                                  Ron



________________________________
From: Eric Biggers <ebiggers=[e-mail]>
Sent: Tuesday, April 28, 2026 2:58 AM
To: [e-mail] <[e-mail]>
Subject: [tcpm] Feedback on draft-ietf-tcpm-tcp-ao-algs-00

I don't support draft-ietf-tcpm-tcp-ao-algs-00 in its current form.
While adding a new algorithm to TCP-AO would be appropriate, the draft
actually proposes adding six new algorithms.  This will create
fragmentation and difficulty for implementers.

Specific comments on the proposed algorithms:

HMAC-SHA3-256, HMAC-SHA3-384, and HMAC-SHA3-512 are unnecessary.  SHA-3
doesn't require the HMAC construction.  If a SHA-3 based MAC is really
desired, a better choice would be KMAC256.  That would be one algorithm,
not three.  However, this still might not be particularly useful: SHA-3
is very slow on most CPUs, and SHA-2 is still considered secure.

Regarding the SHA-2 offerings: HMAC-SHA256-128, HMAC-SHA384-128, and
HMAC-SHA512-128 are mostly redundant with each other.  They're all part
of the SHA-2 family, and the MAC is being truncated to 128 bits anyway.

SHA-384 and SHA-512 do have higher internal cryptographic strength,
which could provide a small motivation for them.  However, the value of
that seems fairly marginal here, given the MAC truncation.  And either
way, we certainly don't need *both* SHA-384 and SHA-512.

I suggest simplifying the proposal to just HMAC-SHA256 for now.  That's
the only one that seems like an obvious choice.  Indeed, SHA-256 is the
usual replacement for the outdated SHA-1.

It may be reasonable to leave the door open to add HMAC-SHA512 and/or
KMAC256, if they could be strongly motivated.  But please do keep in
mind the costs of fragmentation, interoperability failures, and of
implementers having to implement all these algorithms.

I also suggest bringing this topic to the cfrg
(https://urldefense.com/v3/__https://datatracker.ietf.org/rg/cfrg/about/__;!!NpxR!mLXvbt9EFDrV13n2IrY0E7dVrzxZwExIfG4JTjFx0pWTTrVKpVEgFVodlRpJj7ST0f9PLqv7oEQvizyS3VCawdIRAPqqjw2B$ ) for advice.  There are
many people there who could help choose an appropriate algorithm(s).
They could also help ensure it is used in an appropriate way, including
following current best practices for key derivation which the current
draft appears to overlook.

- Eric

_______________________________________________
tcpm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]