Date: Mon, 20 Jul 2026 20:02:18 +0000
From: Eric Biggers <ebiggers@google.com>
To: tcpm@ietf.org
Message-ID: <20260720200218.GA341047@google.com>
References: 
 <178249061156.1804370.3766568479863954134@dt-datatracker-f9b87776f-8pmmg>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <178249061156.1804370.3766568479863954134@dt-datatracker-f9b87776f-8pmmg>
Message-ID-Hash: YE23MDDUENOYNJY42NVK5QHNSTKHT7H6
CC: i-d-announce@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Btcpm=5D_Re=3A_I-D_Action=3A_draft-ietf-tcpm-tcp-ao-algs-05=2Etx?=
	=?utf-8?q?t?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tcpm/rAcV7vHGtIdGGduj0LmUoaX2xs4>

Hi,

On Fri, Jun 26, 2026 at 09:16:51AM -0700, internet-drafts@ietf.org wrote:
> Internet-Draft draft-ietf-tcpm-tcp-ao-algs-05.txt is now available. It is a
> work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the IETF.
> 
>    Title:   Additional Cryptographic Algorithms For Use With TCP-AO
>    Authors: Ron Bonica
>             Tony Li
>    Name:    draft-ietf-tcpm-tcp-ao-algs-05.txt
>    Pages:   26
>    Dates:   2026-06-26
> 
> Abstract:
> 
>    RFC5926 creates a list of cryptographic algorithms that can be used
>    with TCP-AO.  This document expands that list, adding two Message
>    Authentication Code (MAC) algorithms, HMAC-SHA256-128 and
>    KMAC256-128.  For each MAC algorithm, a corresponding Key Derivation
>    Function (KDF) is also added.
> 
>    The MAC algorithms described by this document produce 128-bit (i.e.,
>    16-byte) MACs.  When 16-byte MACs are encoded in TCP-AO, the TCP-AO
>    consumes 20 of the 40 bytes available for TCP options.

I had this reviewed internally as well, and the result is that it
generally looks reasonable.  But there's still a footgun regarding what
is acceptable as a Master_Key.  There's an opportunity to do more to
decrease the chance of misuse.

As a refresher, TCP-AO accepts variable-length ASCII strings as the
Master_Key with no minimum length requirement.  Unfortunately, this
encourages users to input arbitrary passwords, which tend to have low
entropy.  Furthermore, no key stretching is performed, leaving these
passwords vulnerable to brute-forcing.  Some of the problematic language
includes:

  - RFC 5925: "Master_Key - The master_key string"

  - RFC 5926: "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.   Master_Keys SHOULD be random, but
    might not be (e.g., badly chosen by the user).  For
    interoperability, the management interface by which the PSK is
    configured MUST accept ASCII strings, and SHOULD also allow for the
    configuration of any arbitrary binary string in hexadecimal form."

  - draft-ietf-tcpm-tcp-ao-algs-05.txt: "This document RECOMMENDS that
    operators use Master_Keys generated by a cryptographic random number
    generator, or similar.  However, it is understood that they may not
    do so."

Though none of these documents explicitly use the word "password," the
lack of a minimum length and the explicit support for human-readable
ASCII strings makes it easily be interpreted as one.

Not surprisingly, here's how it got paraphrased into the documentation
of Linux's TCP-AO implementation (until I fixed it):

  - https://www.kernel.org/doc/html/v7.0/networking/tcp_ao.html:
    "MACs are produced from the content of a TCP segment using a hashing
    function with a password known to both peers."

So when people actually implement this stuff it becomes "password".

Really, the protocol should just take a 256-bit binary key that MUST be
a cryptographic key.  However, since that wasn't done from the
beginning, requiring it just for the new algorithms would be confusing.

Instead, how about:

  - The new algorithms will require that the master key MUST be *at
    least* 256 bits in length.  (This doesn't necessarily mean 256 bits
    of entropy, given that the key could be an ASCII representation of a
    key; however, this is better than no defense at all.)

  - The "Security Considerations" section should be clearer.  For
    example:

    "Master_Keys SHOULD have at least 256 bits of entropy, and they
    SHOULD be generated by a cryptographic random number generator or
    similar. No key stretching is done, and the use of low-entropy
    secrets (such as passwords) is vulnerable to brute-force attacks. If
    an ASCII string is used, it SHOULD be the hex or base64
    representation of a cryptographic key with at least 256 bits of
    entropy, rather than a human-readable password or passphrase."

- Eric