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

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

Brian, Eric,

Thanks for resolving these issues. I will take the following actions:


  1.
Leave draft-ietf-tcpm-tcp-ao-algs-05, Section 3.1.1 (HKDF-SHA256) as is.
  2.
Migrate draft-bonica-tcpm-tcp-ao-long-algs from SHA384 to SHA256
  3.
Make the changes that Eric recommends in his post<https://mailarchive.ietf.org/arch/msg/tcpm/rAcV7vHGtIdGGduj0LmUoaX2xs4/>.

                                         Ron


________________________________
From: Brian Weis <[e-mail]>
Sent: Thursday, July 23, 2026 9:19 PM
To: Bonica, Ron <[e-mail]>; Eric Biggers <[e-mail]>
Cc: Michael Tuexen <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-ao-algs-05 early Secdir review

Hi Ron & Eric,

Sorry, I”m a little behind the conversation here.

On Jul 21, 2026, at 1:50 AM, Bonica, Ron <[e-mail]> 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.

That’s not necessary, I just wanted to point out previous work done for comparison. The only question here I believe is whether or not to use the HKDF method of producing a master key or not.

Eric makes a good point that the Master-Key can’t be assumed to have full entropy, and it’s hopeful to think an HKDF might mitigate that risk. But the use of a text-based key and a Salt of zeros doesn’t do much to help mitigate the risks over just HMAC-SHA-256. I don’t recall that there are any threats from an on-path or off-path attacker who can only observe the HMAC-SHA-256  tags, so I believe the main threat would be an attacker guessing the Master_key. HKDF doesn’t seem to mitigate that attack. Caveat: I’m not a cryptographer.

Eric mentions adding a requirement for higher-quality keys for these algorithms. If the WG feels that can be appropriately done in an algorithms draft rather than the TCPM specification itself, then that sounds like a good idea. Currently RFC 5925 only specifies the Master_Key as "A byte sequence”.

In any case, if the working group prefers the HKDF construction there’s nothing wrong with that choice.


  1.  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?

From a security perspective, there does not seem to be a need for the larger HMACs. That is, if the extended-options draft provided a 256-bit security level by included the entire 256-bit HMAC output, that would be sufficient for the foreseeable future. As such, that there is no real need for the HMAC outputs larger than 256-bits at the current time or expected to be needed for quite some time.

The main downsides of the higher-level HMACs are performance, as Eric has pointed out, and carrying the entire HMAC output on the wire, which would use more of the extended-options field (384 bits or 512 bits rather than 256 bits). Another consideration is that I would expect custom hardware (i.e., not using x86_64 or arm64) implementing TCP would be more likely to support HMAC-256 because if it’s wider usage than the -386 or -512 versions.

Another way to think about this whether the -386 and -512 HMAC security levels  are meaningful compared to the protection level and guess-ability of the Master-Keys. There’s not much point in specifying an algorithm with such a strong security level as HMAC-SHA-384 if the quality of the Master-Keys keys can’t be guaranteed to be indistinguishable from random.

Thanks,
Brian

                                                                            Ron


________________________________
From: Michael Tuexen <[e-mail]>
Sent: Tuesday, July 21, 2026 10:18 AM
To: Brian Weis <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [tcpm] draft-ietf-tcpm-tcp-ao-algs-05 early Secdir review

> On 21. Jul 2026, at 06:54, Brian Weis via Datatracker <[e-mail]> wrote:
>
> Document: draft-ietf-tcpm-tcp-ao-algs
> Title: Additional Cryptographic Algorithms For Use With TCP-AO
> Reviewer: Brian Weis
> Review result: Not Ready
>
> 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.
Hi Brian,

thank you very much for providing the review in time!
This way your review can be used in the discussion at the WG meeting
later this week.

Best regards
Michael
>
>
> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]