Re: [secdir] secdir review of draft-ietf-lamps-cms-sha3-hash

Wes Hardaker <> Fri, 03 May 2024 09:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2ECAC14F6AE for <>; Fri, 3 May 2024 02:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tiOHFc9fdX_I for <>; Fri, 3 May 2024 02:10:14 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 230C2C14F68D for <>; Fri, 3 May 2024 02:10:13 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id E4BE122843; Fri, 3 May 2024 02:10:12 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 E4BE122843
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1714727413; bh=otxbsfT4sLTJZ4/RPNAgmfq3t5lsDhHiQqAIOGCkcyE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UR/Y+8u1ZRvdrXtwtxtggE8r8ob6RBrsaKeA93Tk6HpO7DMaBdLm2Dnc5tMDYQ7zA kbbAdzobS2Gw5fhzXN5FbGfe+C9Eo6nbilSJeDjwcIwMGgfJzPG3tu8rgpBdF6FKl7 kM3AzSpW/n8GKgOgS/neDnMF7CCejuBmduRNxU3c=
From: Wes Hardaker <>
To: Russ Housley <>
Cc: Wes Hardaker <>,, IETF SecDir <>, IESG <>
In-Reply-To: <> (Russ Housley's message of "Thu, 2 May 2024 12:25:08 -0400")
References: <> <>
Date: Fri, 03 May 2024 02:10:11 -0700
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-lamps-cms-sha3-hash
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 May 2024 09:10:19 -0000

Russ Housley <> writes:

Thanks for the response Russ.  Trimming back-and-forth to just a few

> > - section 3.1 and beyond: there is a discrepancy between how OIDs are
> >  used in some places and the fully qualified OBJECT IDENTIFIERs are
> >  used in other places.  I note the appendix uses OID everywhere, but
> >  the copied versions into the sections above.
> The OID convention was used only is Section 3.1 because the names that
> were already assigned in RFC 8017 are so long.  If you find this
> confusing, the impact will be two lines for each of them.

It makes more sense to do the inverse then and change the rest of the
invocations to OID as well.  This actually matches the real module's use

But there is no "wrong" way here.  Your choice in the end.

> > - section 5.2: suggest changing "If any other value is used for S" to
> >  "If any value is used for S", since you just said it must be absent if
> >  there was no label.  And unless "absent" is a value, then the word
> >  "other" doesn't apply.
> Based on an earlier comment, this was changed to:
>    When the id-kmac128 or id-kmac256 is used as part of an algorithm
>    identifier, the parameters field MUST be absent when there is no
>    customization label S.  If any value is provided for S, then the
>    parameters field MUST be present and contain the value of S, encoded
>    as Customization.

Thanks...  I actually reviewed an earlier version and then looked at the
diff to fix my review, but missed one.

>    ...  Instead of brute force searching the whole
>    key space, an attacker may find it much easier to reproduce the PRNG
>    environment that produced the keys, and then search the resulting
>    small set of possibilities.  ...

That's definitely better, thanks.

Wes Hardaker