Return-Path: X-Original-To: art@mail2.ietf.org Delivered-To: art@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C1D5911493375; Fri, 10 Jul 2026 08:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783695861; bh=eZ4cMuF5K6yHkfD+KghW1clkLtpDTB+IN7y1QESwfIM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=jgN1a6wxJ4YqBv2VDciyGXl2G5QYasfpp5yqxv/QjjyfxgXbuACkrRrgv8oOLBqzx 2LE2dB87A+hEJEsybpqKVhTJuh+GT5Xy4HLCvoeup0ZsfNGUeXM22CGdT/9tHScHIL vRlWyTo87/Cl2tR5VC8bjCHuwlbCgH1osxPz4pWE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=vigilsec.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEX7ADY0YSDZ; Fri, 10 Jul 2026 08:04:21 -0700 (PDT) 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 ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EE3221149336E; Fri, 10 Jul 2026 08:04:20 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 122691A17F2; Fri, 10 Jul 2026 11:04:14 -0400 (EDT) Received: from smtpclient.apple (unknown [170.85.70.202]) (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 D51A11A1C0F; Fri, 10 Jul 2026 11:04:13 -0400 (EDT) From: Russ Housley Message-Id: <4EB2F309-0DB7-4726-859A-4E896F5D19D7@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E4BA7CF9-D056-4D52-87BD-ED984C537FC0" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Date: Fri, 10 Jul 2026 11:04:03 -0400 In-Reply-To: To: "K Tirumaleswar Reddy (Nokia)" References: <178336724420.330109.17306090490408859598@dt-datatracker-57b5d8f849-v5cht> X-Mailer: Apple Mail (2.3864.600.51.1.1) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vigilsec.com; h=from:message-id:content-type:mime-version:subject:date:in-reply-to:cc:to:references; s=pair-202402141609; bh=zSGSCIaVhKh0a4wXSb/IPuS0M7oFT16U4o7DThJqR4s=; b=PIo6Mq1z1DouEm5S+bOn+7YiDdiZfoagCCL++IpnzRqoKNLQNuAkM98KU+zNJuPtkyKauc7P7+whyc3Jl+P/cvZIYKthTCOygmZNgbb2VnmNeRpXVInNPLJKsVveR1oeGiwo4R2kkrHMMlkqWI/KcAT5/15arwwYViMAEk0RS9TQ5iUj6Ugg9WUyq1qAIH2NyL1SFZrl/jzPhzD+dEbQ/uP9AQQQ26zuKi4HnXfE7OMrPJ+q0Lq8TZBjUUJrfQ2hYhiWLCjuvW8Xd1fG1p+tPmGUurRvxUJ9WuvpXEFFjCPujItXBEqWG4UTRPUUW1IyyEXOq8yKQPNkBX0ntaE6RQ== X-Scanned-By: mailmunge 3.09 Message-ID-Hash: J5SYKFAZK2ATKCPY3I7BRVSPA4YR3WWI X-Message-ID-Hash: J5SYKFAZK2ATKCPY3I7BRVSPA4YR3WWI X-MailFrom: housley@vigilsec.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-art.ietf.org-0; header-match-art.ietf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "art@ietf.org" , "draft-ietf-pquip-pqc-hsm-constrained.all@ietf.org" , "last-call@ietf.org" , "pqc@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bart=5D_Re=3A_draft-ietf-pquip-pqc-hsm-constrained-06_ietf_last_?= =?utf-8?q?call_Artart_review?= List-Id: Applications and Real-Time Area Discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_E4BA7CF9-D056-4D52-87BD-ED984C537FC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My comments are resolved by this PR. Russ > On Jul 10, 2026, at 1:28=E2=80=AFAM, K Tirumaleswar Reddy (Nokia) = wrote: >=20 > Thanks Russ for the review, raised PR = https://github.com/tireddy2/hsm-pqc/pull/77 to address them. > =20 > -Tiru > =20 > -----Original Message----- > From: Russ Housley via Datatracker >=20 > Sent: Tuesday, July 7, 2026 1:17 AM > To: art@ietf.org > Cc: draft-ietf-pquip-pqc-hsm-constrained.all@ietf.org = ; = last-call@ietf.org ; pqc@ietf.org = > Subject: draft-ietf-pquip-pqc-hsm-constrained-06 ietf last call Artart = review > =20 > =20 > CAUTION: This is an external email. Please be very careful when = clicking links or opening attachments. See the URL nok.it/ext = for additional information. > =20 > =20 > =20 > Document: draft-ietf-pquip-pqc-hsm-constrained > Title: Adapting Constrained Devices for Post-Quantum Cryptography > Reviewer: Russ Housley > Review result: Almost Ready > =20 > I am the assigned ART-ART reviewer for this draft. Please treat these = comments just like any other last call comments. > =20 > =20 > Document: draft-ietf-pquip-pqc-hsm-constrained-06 > Reviewer: Russ Housley > Review Date: 2026-07-06 > IETF LC End Date: 2026-07-07 > IESG Telechat date: unknown > =20 > Summary: Almost Ready > =20 > =20 > Major Concerns: > =20 > Section 3.1.3: This section needs a warning about the strength of the = TLS keys and the key-encryption keys. These need to be at least as = strong and the PQC private key that is being protected. > =20 > =20 > Minor Concerns: > =20 > Section 3: The terms 'IDevID' and 'LDevID' come from IEEE 802.1AR. = Please include a reference to this document or some other place that has = definitions. > =20 > Section 3.1.1: The text says: > =20 > In many embedded deployments, SLH-DSA is > expected to be used primarily for firmware verification, in which > case key generation is performed offline and does not impact device > performance. However, in scenarios where the device generates its > own SLH-DSA key pairs, the higher key generation cost may influence > seed-storage design decisions and depend on performance > considerations or standards compliance (e.g., PKCS#11). > =20 > In this case, the devide does not have access to the SLH-DSA private = key. > The use of 'off;ine' is not appropriate. The private key is known = only > to the firmware signer; the firmware verifier only knows the public = key. > =20 > Section 3.1.3.1: Why not other security protocols? The end-to-end = nature of TLS is important, but DTLS has that property too. Maybe it = would be better to list the properties of the security protocol that is = needed, and provide TLS as an example. Further, please prove a = reference for TLS. > =20 > Section 3.1.3.2: It might be better to point to RFC 5649. The = expanded private key may not align with the block size of the symmetric = algorithm. > =20 > Section 6.1.1: The text says: > =20 > In firmware update and secure boot scenarios, signature = verification > is typically performed during early boot stages, where the = bootloader > has exclusive access to system resources. In such environments, = the > practical impact of resource constraints on signature verification = is > reduced compared to general runtime environments. > =20 > The discussion of new firmware installation deserves a discussion. In = some devices, it is important to check the next generation of firmware = while the current generation is running. The goal is minimal downtime = during a swap. > =20 > =20 > Nits: > =20 > In the datatracker, the value for 'Consensus boilerplate' needs to be = set. > =20 > Section 3,1.2: s/seeds with each request/seeds for each operation/ > =20 > Section 4: s/flavours/flavors/ > =20 > Section 6: s/due to

their construction/due to their = construction/ > =20 > IDnits complains thet: > =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to = have RFC > 2119 boilerplate text. --Apple-Mail=_E4BA7CF9-D056-4D52-87BD-ED984C537FC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My comments are resolved by this = PR.

Russ

On Jul 10, 2026, at 1:28=E2=80=AFAM, K Tirumaleswar = Reddy (Nokia) <k.tirumaleswar_reddy@nokia.com> wrote:

Thanks Russ for the = review, raised PR https://github.com/tireddy2/hsm-pqc/pull/77 to address = them.
 
-Tiru
 
-----Original Message-----
From: Russ Housley via = Datatracker <noreply@ietf.org> 
Sent: Tuesday, July 7, = 2026 1:17 AM
To: art@ietf.org
Cc: draft-ietf-pquip-pqc-hsm-constrained.all@ietf.org; last-call@ietf.org; pqc@ietf.org
Subject: = draft-ietf-pquip-pqc-hsm-constrained-06 ietf last call Artart = review
 
 
CAUTION: This is an = external email. Please be very careful when clicking links or opening = attachments. See the URL nok.it/ext for additional = information.
 
 
 
Document: = draft-ietf-pquip-pqc-hsm-constrained
Title: Adapting = Constrained Devices for Post-Quantum Cryptography
Reviewer: Russ Housley
Review result: = Almost Ready
 
I am the assigned ART-ART reviewer for this draft. Please = treat these comments just like any other last call = comments.
 
 
Document: = draft-ietf-pquip-pqc-hsm-constrained-06
Reviewer: Russ Housley
Review Date: = 2026-07-06
IETF LC End Date: = 2026-07-07
IESG Telechat date: = unknown
 
Summary: Almost Ready
 
 
Major = Concerns:
 
Section 3.1.3: This section needs a warning about the = strength of the TLS keys and the key-encryption keys.  These need = to be at least as strong and the PQC private key that is being = protected.
 
 
Minor = Concerns:
 
Section 3:  The terms 'IDevID' and 'LDevID' come from = IEEE 802.1AR.  Please include a reference to this document or some = other place that has definitions.
 
Section 3.1.1: The = text says:
 
   In many embedded deployments, SLH-DSA = is
   expected to be used = primarily for firmware verification, in which
   case key generation is performed offline and = does not impact device
   = performance.  However, in scenarios where the device generates = its
   own SLH-DSA key pairs, = the higher key generation cost may influence
   seed-storage design decisions and depend on = performance
   considerations or = standards compliance (e.g., PKCS#11).
 
In this case, the = devide does not have access to the SLH-DSA private = key.
The use of 'off;ine' is not = appropriate.   The private key is known = only
to the firmware signer; the firmware = verifier only knows the public key.
 
Section 3.1.3.1: Why = not other security protocols?  The end-to-end nature of TLS is = important, but DTLS has that property too.  Maybe it would be = better to list the properties of the security protocol that is needed, = and provide TLS as an example.  Further, please prove a reference = for TLS.
 
Section 3.1.3.2: It might be better to point to RFC = 5649.  The expanded private key may not align with the block size = of the symmetric algorithm.
 
Section 6.1.1: The = text says:
 
   In firmware update and secure boot scenarios, = signature verification
   is = typically performed during early boot stages, where the = bootloader
   has exclusive access to = system resources.  In such environments, the
   practical impact of resource constraints on = signature verification is
   reduced = compared to general runtime environments.
 
The discussion of new = firmware installation deserves a discussion.  In some devices, it = is important to check the next generation of firmware while the current = generation is running.  The goal is minimal downtime during a = swap.
 
 
Nits:
 
In the datatracker, the value for 'Consensus boilerplate' = needs to be set.
 
Section 3,1.2: s/seeds with each request/seeds for each = operation/
 
Section 4: s/flavours/flavors/
 
Section 6: s/due = to<br/><br/>their construction/due to their = construction/
 
IDnits complains thet:
  =3D=3D = The document doesn't use any RFC 2119 keywords, yet seems to have = RFC
     2119 = boilerplate = text.

= --Apple-Mail=_E4BA7CF9-D056-4D52-87BD-ED984C537FC0--