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

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

Folks,

Regarding the first issue, Eric and Brian have much more expertise than I. I will ask them to reach consensus and I will do whatever they recommend.

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.

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?

                                                                                    Ron


________________________________
From: Eric Biggers <[e-mail]>
Sent: Tuesday, July 21, 2026 7:09 PM
To: Bonica, Ron <ronald.bonica=[e-mail]>
Cc: Michael Tuexen <[e-mail]>; Brian Weis <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-tcp-ao-algs-05 early Secdir review

On Tue, Jul 21, 2026 at 08:50:29AM +0000, Bonica, Ron wrote:
> Hello Brian,
> Thanks for your careful review.
> Two questions:
>
>   1.
> Do you recommend that we replace the contents of draft-ietf-tcpm-tcp-ao-algs-05, Section 3.1.1 with the contents draft-nayak-tcp-sha2-03, Section 3.1.1? Should we also replace the section title? If so, I would be happy to do that.

FYI, earlier I recommended the separate entropy extraction step (which
was concretely implemented as HKDF-SHA256-Extract + HKDF-SHA256-Expand)
because TCP-AO explicitly allows the Master_Key to be an ASCII string.

TCP-AO's support for ASCII strings was a mistake in my opinion, but it's
perhaps too late to fix.  I am however recommending that the new RFC
require that the Master_Key length be at least 256 bits and give clearer
guidance about choosing Master_Keys
(https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tcpm/EG9q7Eylk2G09nMUNJ_GkYwxGWs/__;!!NpxR!isVfuwoo3Oyl_CO4fRHGZRs-NsDtqD1nzkLqSlI5A1tfhO9P7XmZutP8gWGdbhKLbWYNNxVSvtrUg3V1hQ$ ),
especially emphasizing that they should be high-entropy keys rather than
human-readable passwords.

Regardless, considering that it could be an ASCII string, the Master_Key
might not have full entropy for its length, and the entropy might not be
distributed uniformly.  An entropy extraction step is the usual way to
handle that and turn it into a proper cryptographic key (though
sufficient entropy still needs to be present).

The caveat here is that in practice HMAC seems to act as both an entropy
extractor and expander simultaneously (assuming a non-adversarial
entropy source, which has to be assumed here anyway, since no
independent salt is available).  So in practice, just doing the one-step
HMAC is *probably* fine.  But as I've said before, I'm just concerned
that this is an informal argument and it effectively amounts to a
criticism of the standard KDF design practice.  Standard security proofs
for HMAC assume the key is chosen uniformly at random, which isn't the
case with an ASCII string.

If you want to do it anyway as an optimization and for consistency with
how TCP-AO uses HMAC-SHA1, I recommend finding some citations for the
approach of using one-step HMAC as an extract+expand KDF.

Alternatively, the support for ASCII strings could be reconsidered...
Maybe it's not too late to fix?  Note that support for ASCII strings in
the configuration files of TCP-AO software does *not* require that the
protocol itself support ASCII strings.  The hex decoding, base64
decoding, etc. can be a user interface implementation detail, with the
actual TCP-AO protocol implementation being passed a binary key.

>   2.  If we implement HMAC-SHA256 instead of HMAC-SHA384, TCP-AO will still consume 36 bytes, leaving only 4 bytes for other options. So, we will still need to implement draft-bonica-tcpm-extended-options. Given that, should we implement hmac-sha256 or skip ahead to hmac-sha384 or even hmac-sha512?

There's no cryptographic need for a 384-bit or a 512-bit MAC, though
sometimes people like to use HMAC-SHA512 anyway for the (perceived)
higher internal security strength.  Has anyone asked for that here,
though?

- Eric