Early Review of draft-ietf-tcpm-tcp-ao-algs-05
review-ietf-tcpm-tcp-ao-algs-05-secdir-early-weis-2026-07-20-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

Because this is an early review I’ve marked it “Not Ready”, but that is not a
pejorative marking.

This document proposes two new MACs for the TCP Authentication Option:
HMAC-SHA256-128 (using a HKDF-SHA256 KDF)  and KMAC256-128 (using KMAC256-KDF).
The two MACs return a 128-bit output due to the limited number of TCP option
octets. It is generally accepted that no more than 128-bits option octets are
available for TCP-AO.

The authors asked some questions as part of the early review.

Q1: (paraphrasing) Are these algorithms significantly better than the ones
originally specified in RFC 5926?

A: The algorithms in RFC 5926 produce a 96-bit output, which limits them to a
96-bit security level. Since the proposed MAC/KDF pairs (considered to have
256-bit security) are producing a 128-bit output, they have a 128-bit security
level and thus would be better than the original algorithms.

Q2: Would other algorithms with similar output length be significantly better
than the proposed ones?

A: I am not aware of any commonly used algorithms that are better.  Having an
algorithm based on SHA-256 is a good idea; I will note that a draft
(draft-nayak-tcp-sha2-03) was submitted to TCPM a few years ago that also
defined a HMAC-SHA256-128 method, although with a different KDF.

I have a couple of comments on the draft:

1. Although allowed, it’s not clear to me that the two-step method using
HKDF-Extract() with a salt of zeros provides much additional value over using a
one-step traffic key derivation (e.g., as is done for RFC 5926). An all-zero
salt is satisfactory if the Master_Key is guaranteed to come from a good source
of entropy. However, when keys are manually entered into key tables (e.g., RFC
7210), the master key cannot be guaranteed to have sufficient entropy.

A KDF method similar to RFC 5926 and draft-nayak-tcp-sha2-03 might be more
efficient and should have an equivalent level of security.

However, the all-zero salt is allowed, and there doesn’t seem to be any
particular downside of using HKDF other than the additional TCP processing for
HKDF-Extract().  You may have another specific reason for specifying using HKDF.

2. It would be worth specifying which 128 bits of the HMAC-SHA256 output are used
for HMAC-SHA256-128. I’m sure you meant for the 256-bit output to be truncated
(i.e., use the first 128 bits) but the draft should be precise.

The authors also asked some questions regarding a related draft
(draft-bonica-tcpm-tcp-ao-long-algs), which assumes an available solution that
extends TCP Option space, thus allowing for a TCP-AO MAC algorithm with a larger
tag.

Q3: (paraphrasing) Draft-bonica-tcpm-tcp-ao-long-algs specifies HMAC-SHA384 and
KMAC-384 MACs. Are they significantly better than the ones proposed in
draft-ietf-tcpm-tcp-ao-algs-05?

A: Specifying a TCP-AO algorithm for 384-bit algorithms is sufficiently  better,
and the 384-bit tags defined in the the long-algs draft should result in a
security level of 384 which is much greater than 128.

However, it’s not clear that there is any need for this level of security in
TCP-AO when no algorithm specifying a 256-bit security level has been specified.

One alternative would be to define the same algorithms as in
draft-ietf-tcpm-tcp-ao-algs but with an output of 256 bits (i.e., not truncating
the tags), which should give 256 bit security. NIST has not specified a timeframe
in which they believe 256-bit security will be deprecated.

Q4: Would other algorithms with similar output length be significantly better
than the proposed ones?

A: None of which I am aware.

Q5: What is the timeline for switching to longer MACs like in
draft-bonica-tcpm-tcp-ao-long-algs? Is there an immediate need, for example due
to PQ.

A: I know of no timeline specifying a need beyond 256-bit security.
Post-quantum crypto is not as dire a threat to hash functions as some other
cryptographic algorithms, and it seems that hash functions with a 256-bit key
are safe for now. Having said that, some government organizations are
considering 384-bit keys for some application, but I wouldn’t expect threats to
TCP-AO to warrant that level of security for some time.