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

[Eric Biggers <[e-mail]>]

On Fri, May 29, 2026 at 10:10:51PM +0000, Bonica, Ron wrote:
> Eric,
> 
> Thanks for the careful review. I have just posted a new version and hope that it addresses all your concerns.
> 
> Please take a close look at Section 3.2.2. Spending an afternoon with SP 800-56C Revision 2 has left me cross-eyed and perspiring ;-)

Shouldn't there be an appendix with test vectors for the KDFs?  That
would be helpful for implementers to test that they implemented them
correctly.

There should be a citation to https://doi.org/10.6028/NIST.SP.800-185
for the definition of KMAC256.

Overall, I think there are still opportunities to present the
information in a more straightforward way, especially when defining the
KDFs.  For example, both of the new KDFs are used only to generate 32
bytes of output.  Yet, the text has generic language like "L is the
Output_length argument provided to the KDF interface divided by 8" and
"The output key length depend on the specific cryptographic algorithms
for which the keys are needed."  So the reader then has to refer to
other parts of the text to find that actually L is just 32.

I guess the intent was to logically decouple the KDFs from the MAC
algorithms.  But that doesn't reflect the reality where they are indeed
coupled so that the KDF and MAC use consistent algorithms.

- Eric