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

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

Eric,

Good catch! I will make that change in the next version of the draft!

Thanks!

                                    Ron

________________________________
From: Eric Biggers <ebiggers=[e-mail]>
Sent: Wednesday, April 29, 2026 6:16 PM
To: Bonica, Ron <[e-mail]>
Cc: Bonica, Ron <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [tcpm] Re: Feedback on draft-ietf-tcpm-tcp-ao-algs-00

On Tue, Apr 28, 2026 at 05:42:14PM +0000, Bonica, Ron wrote:
> Folks,
>
> I would be happy to trim the draft down to 1 KDF (HMAC-SHA236) and one MAC (HMAC-SHA256-128).
>
> Does the WG agree?

Is the missing entropy extraction planned to be fixed as well, or is
that issue planned to be carried over from the HMAC-SHA1 support?

RFC5926 is clear that the user-provided "key" doesn't necessarily
contain full entropy for its length:

    "The Master_Key is used as the seed for the KDF.  We assume that
    this is a human-readable pre-shared key (PSK); thus, we assume it is
    of variable length."

Yet, TCP-AO uses Master_Key directly as an HMAC-SHA1 key, without first
running an entropy extractor on it (e.g., passing it as the message into
HMAC-SHA1 with an all-zeroes key).  The proposed additional algorithms
carry over this same issue.

This doesn't follow cryptographic best practices, and it makes the
system hard to analyze.  Specifically its security depends on the
internal structure of HMAC, rather than on HMAC simply being a PRF.
I think it's probably okay in practice, but it's an odd quirk that
shouldn't really exist, especially in a new proposal.

It can be fixed by adding an entropy extraction step, like what TCP-AO
already specifies for AES-128-CMAC.

Alternatively it could be required that the user-provided key has full
entropy.  But I wouldn't recommend that: it would be error-prone to
introduce that usage requirement into TCP-AO now, when it didn't have it
from the beginning.

- Eric