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

Wes Hardaker <wjhns1@hardakers.net> Wed, 01 May 2024 15:51 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0D87AC14F5F2 for <secdir@ietfa.amsl.com>; Wed, 1 May 2024 08:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LY_nTXFgt6p5 for <secdir@ietfa.amsl.com>; Wed, 1 May 2024 08:51:30 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net []) (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 ietfa.amsl.com (Postfix) with ESMTPS id 3AEB8C14F695 for <secdir@ietf.org>; Wed, 1 May 2024 08:51:30 -0700 (PDT)
Received: from localhost (unknown []) (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 mail.hardakers.net (Postfix) with ESMTPSA id C84F62341C; Wed, 1 May 2024 08:51:29 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net C84F62341C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1714578689; bh=sVDXe4mkYqiSDbyGARknkLrnvkEvKmr42BC697RZG2w=; h=From:To:Subject:Date:From; b=XSUZcvRrMi5dV+U0RUICaRmRD6KV6Csf1S+MYmAxym6MAM+cNcfrZqZyGZlptmulv PZePvUFssj4sCeyVxeetq2rUE8ffEAxnI1WoFVNK8Wnu3qWWO40o7TXy1W/ZoZlaSn sMg3evcOFZ1tOVeFCt3dJvAcXtJE4P3OdV4+02M8=
From: Wes Hardaker <wjhns1@hardakers.net>
To: draft-ietf-lamps-cms-sha3-hash.all@ietf.org, secdir@ietf.org, iesg@ietf.org
Date: Wed, 01 May 2024 08:51:29 -0700
Message-ID: <ybly18th6ny.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-NTH1GHCLZ74kGFKoaIPgXFXJTQ>
Subject: [secdir] secdir review of draft-ietf-lamps-cms-sha3-hash
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2024 15:51:35 -0000

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.

The summary of the review is: ready

In general this is a well written document.  I have some minor
thoughts/nits below.  Note that I'm not a CMS expert, but certainly have
a decent amount of generic background (including ASN.1).

- Section 2: The first paragraph has an odd line break after the
  first sentence.  I'm not sure what formatting has caused this, but it
  is present in both the txt and pdf versions at least.

- Section 2 paragraph 2: it would be helpful to less familiar readers to
  say what the fields were inside of what CMS structure.

- section 2, generally: by specifying exactly the list of fields where
  this applies, it does limit future extensions to the base protocol to
  not add new fields without updating this document as well.  This may
  be by design though.

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

- Why is sigAlgs and hashAlgs defined in this module but RSAPublicKey is
  imported.  Even though sigAlgs and hashAlgs are simply references,
  wouldn't it be better to import them from somewhere else since I don't
  think you're actually defining them.  (my memory says you can import
  simple OIDs from other places).  My purist had would rather import
  them rather that duplicate the definition, but this is a choice to
  some extent (and yes, there is no actual harm in defining it in
  multiple places or even having two different names assigned to the
  same OID but then you get into proper coding practice and typos and

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

- section 5.2: it would be kinda helpful in the paragraph to also state
  that S must be encoded as an OCTET STRING even though it's in the
  definition too.

- section 5.3: you state "an algorithm identifier from section 2 is
  carried in the parameter" but don't state what parameter.  Since this
  is sentences later, I'd suggest adding "KEMRecipientInfo" in front of
  parameter (and if I got the parameter wrong, then you already have one
  failed interpretation!)

- section 6: suggest "...authentication is not provided" ->
  "...authentication is not assured".

- section 6, sentence starting with "An attacker may find"...  The first
  time I read this I had to read it multiple times to pull it all in and
  marked it as "awkward".  Now I seem to understand it better, but I'll
  flag it as "could use some simplification and probably broken in 2" if
  you want to do it to help past-me.

- I find it odd that the appendix doesn't have a letter and only a
  title.  When there is only one, I suppose this makes sense but I
  vaguely normally remember seeing "Appendix A" even when there was only
  a single appendix.  maybe.

Wes Hardaker