Re: [lamps] WGLC for draft-ietf-lamps-cms-sha3-hash

Russ Housley <housley@vigilsec.com> Wed, 31 January 2024 17:33 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84337C14F6B5 for <spasm@ietfa.amsl.com>; Wed, 31 Jan 2024 09:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSLk0oMM4u-c for <spasm@ietfa.amsl.com>; Wed, 31 Jan 2024 09:33:37 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (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 204F3C14F682 for <spasm@ietf.org>; Wed, 31 Jan 2024 09:33:37 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 112DF710C3; Wed, 31 Jan 2024 12:33:36 -0500 (EST)
Received: from smtpclient.apple (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 031F670F53; Wed, 31 Jan 2024 12:33:35 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <F9E9ACCB-9159-4CB3-BC47-B091C480A216@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F02950E-CCF9-4614-A4BA-02BE20A1F5B3"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Wed, 31 Jan 2024 12:33:25 -0500
In-Reply-To: <09a101da5450$b9e4afe0$2dae0fa0$@gmail.com>
Cc: SPASM <spasm@ietf.org>
To: Daniel Van Geest <daniel.vangeest.ietf@gmail.com>
References: <SN7PR14MB6492B10C0593B89D36FE221E837D2@SN7PR14MB6492.namprd14.prod.outlook.com> <CH0PR11MB573905E2C705F61F1529E63C9F7D2@CH0PR11MB5739.namprd11.prod.outlook.com> <09a101da5450$b9e4afe0$2dae0fa0$@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/7fY92wogoqz0ZNpDMU1NLpnUjoo>
Subject: Re: [lamps] WGLC for draft-ietf-lamps-cms-sha3-hash
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2024 17:33:41 -0000

Daniel:
> 
> These will be useful for KEMRI with ML-KEM since it uses lots of variants of SHA3 and SHAKE under the covers so we will want a KDF using at least one of those.
>  
> While going over the draft I just found a few nits:
>  
> Section 3.1:
> Trailing braces on the following line:kmac
>                 The RSASSA PKCS#1 v1.5 is defined in [RFC8017]}}.
>  
> Section 5.1:
> “algorithm” is misspelled:
>                 [I-D.ietf-lamps-cms-kemri] is one place where algrithim identifiers
>  
> Section 6:
> Remove either “cryptographics” or “such” from the following line:
> number generators (PRNGs) to generate cryptographic such values can

These are all fixed.  Thanks for the careful read.
 
> The id-alg-hkdf-with-sha3-* object identifiers are currently TBD.  Since cms-kemri and cms-kyber implementation and interop is going on right now in the hackathon group, it would be nice to have those assigned.  Is it too late for early assignment?  Is it too early for normal assignment?  I don’t know if those OIDs will be the ones recommended by cms-kyber, but it would be nice to have some OIDs for specs that aren’t paywalled (kdf2, kdf3).

We can get early assignment if people need them for code, but normal practice is for early assignment to be temporary.  The temporary assignment becomes permanent when the RFC is published.

Russ