Return-Path: X-Original-To: spasm@mail2.ietf.org Delivered-To: spasm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7D4FE24610A7 for ; Sat, 3 May 2025 02:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIMWL_WL_MED=-0.001, 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.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 YGhBp1d60u4N for ; Sat, 3 May 2025 02:48:28 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8EFD32461094 for ; Sat, 3 May 2025 02:48:28 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-e73e9e18556so2521343276.0 for ; Sat, 03 May 2025 02:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1746265708; x=1746870508; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/nyqVMTugwmtSAlXP4kZOu6DrTMUhV4hdQoTYRNE2f4=; b=G+kVpfrQS/sioA8jg4pe3ZLrAJVuAQon3jrZC0zDatbTm81now7/Wpf4vBh7Y1vFiM x6Hw49wbK9t6bPogb8Q7BqvO0In7aebTKdqR3VsNXdy+KIrjY3IHedkzT3nq7Ndxa/B3 YNbdw3lE7+C8Qfz/9RTS4XQAmgshvW2qz4g+9c0krFfxQP7PXidzLOmgKNHq4BO7mGVJ XGdJfChA1FO5i4E7+3vU5tEJ+xUVRtgpyymcIK5HUa56ifyG3N0Vur+hGvgsmcFQ+nH4 L8rYWiDA1u/rcVmEtI0qufewEgCcu9Al8PFQdPnCCx0qOFKWmc71/yXKsIvHRNoUQy79 vS+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746265708; x=1746870508; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/nyqVMTugwmtSAlXP4kZOu6DrTMUhV4hdQoTYRNE2f4=; b=AoW322CC6kJ6VU6NLGnmBVWKgiV09OVddsBGywX043yH/PnicPFOgYcm3TV7hJt1Lm C1qjxQI02xiQ8/656r81q8FjdnKGX4XGbxeeIs6wKPqfzYZTGT0Y5RNEjCo0+q6I1S6t j4IGpYC6aDems9pAhcE9I+Vvl9M2QXIE27zlXmUkUECuKvHnh9xs//v2eyXi5Romv3fM 4sumQRh2M8gNaJhgvV5g6/tA2C9dTzE3v9JyD/dgdQ3/G9Wrf9V/S0uO9hM1msIVVs7Y ePd+CzMa2KZoJuQnpJHUCCqMMBayB5k4BF05vd0Qj7ZJ+ihHMfxHN9Z2mGIPmyMpVyWI DR2A== X-Gm-Message-State: AOJu0YwsPe9k9xy3cgQ/TId0mN6a+/15wsH+ibm1oSqBxmTpzBzVWOQZ /0KQH8VlU2rLfOBk2eR8EVOAjKDtoPk+Tjy83ZkK9THD8BcUseJ5PQTJxIjD2X0MQuz2m7lcCeQ jnN50TJfqKelVVxAu2yo4fGec1P4Bv5agOsbRVg== X-Gm-Gg: ASbGncv/XPzogsj99ak3819j6XenRVPUgsBFO5lOe4LYBby9s8KzB1u8glg7Blh2Nux gRtH53qhPp4M5Xn8KavqwjWMKPHemTsy6YCcDH4ohEYMFNzfmzhyccwLddKhViWrVMzosbxKqGe +5F7704/EVKLmdpDvb0b5Iy7js8PM/eXUhr7FUHyNI X-Google-Smtp-Source: AGHT+IEys+Z3hqkw4w3xG+uZjqJQOwFNYkTrCocI2hkuLLDvdTE78BL9cDFGcf3oWcfJns4mqhW92jMK3xxqlu12cck= X-Received: by 2002:a05:6902:1405:b0:e73:1645:914f with SMTP id 3f1490d57ef6-e752467997cmr13364425276.3.1746265707874; Sat, 03 May 2025 02:48:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bas Westerbaan Date: Sat, 3 May 2025 11:48:16 +0200 X-Gm-Features: ATxdqUHDp_ffJzrxlYVqnO_DherIa3jgM1AUUZHbbegIfGRkhUY8f8R6T_ITpOQ Message-ID: To: Deb Cooley Content-Type: multipart/alternative; boundary="0000000000003418d90634382b8c" Message-ID-Hash: WYZEVFE4MLXW4ETFX44INE5AE2QTVOC6 X-Message-ID-Hash: WYZEVFE4MLXW4ETFX44INE5AE2QTVOC6 X-MailFrom: bas@cloudflare.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: LAMPS WG , draft-ietf-lamps-dilithium-certificates.authors@ietf.org, LAMPS Chairs X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Blamps=5D_Re=3A_AD_comments_on_draft-ietf-lamps-dilithium-certif?= =?utf-8?q?icates?= List-Id: This is the mail list for the LAMPS Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003418d90634382b8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Deb, Thank you for your comments. Section 1.1: Is there a decent source for terminology? If so, list it here. If there isn't, that's fine too. Perhaps PQUIP=E2=80=99s pqc-engineers or hybrid-terminology comes closest, = but it doesn=E2=80=99t seem to be an ideal reference. Any terminology in particula= r you=E2=80=99d like to see defined? Section 2, algorithm: Nit: add (OID) after 'an object identifier'. Addressed in [1]. Section 2, last sentence: ctx is not defined, nor used in the main part of the draft, only in Appendix D. I would define it here. If it only applies in the Appendix D situation, then I would move the statement (and definition) there. It applies to the main document. In [2] we make the reference more explicit= . Section 4: the ASN.1 is 'BIT STRING', the description is 'byte stream' or 'byte string'. Is it worth making it clear that these are all the same thing? I realize that the ASN.1 tags are fixed, but the explanatory text is not. ('OCTET STRING' is a whole other thing, so I'm leaving it out of this comment) [I realize this is a ridiculously picky comment.] Does the change in [1] address this sufficiently? Section 8, last sentence: 'random seed xi' is called 'seed' or '32-byte seed (xi)' everywhere else in the draft. Is it a loss of rigor to delete the word 'random'? (also see my comment on Section 10) The =E2=80=9Crandom=E2=80=9D is meant to signal that we=E2=80=99re in the c= ase that the seed is randomly generated within the function, instead of being provided externally. What about making it an adverb on =E2=80=9Cgenerated=E2=80=9D a= s in [1]? Section 10, para 3: I struggled with this paragraph. What's the point? have you buried the lead? If the point is 'poor entropy', then I think you lead with that. If the point is side channel protection, move that to para 4? I think you can separate these two attack surfaces. In addition: First two sentences: There are two modes, deterministic and randomized. Second sentence is 'non-deterministic', change that to 'randomized'? Sentence 3: there is a "private random seed (rho')" which I'm assuming is a different value. Any chance we can reinforce that this is different from 'seed xi'? throughout para 3: rnd, rng, spell them out. Clarify that the 256-bit string is rnd. random for the randomized version and a constant string for the deterministic version. I couldn't quite tell if 'rng' was a typo. In https://github.com/lamps-wg/dilithium-certificates/pull/139 we moved and tightened up the section. Does this work for you? Section 10, para 5: Meh.... the ability to export/lose control of a private key leaves an issue with non-repudiation, no? I'm fine with the paragraph as it stands, but add something to convey the risk of private key exposure. [I will note that I might also disagree with non-repudiation as a 'fundamental security property', but that is a personal bias.] We tweaked the wording. https://github.com/lamps-wg/dilithium-certificates/pull/140 Section 10, last sentence: 'These properties', which properties? The properties in this section? Is this a security consideration? Or does it belong up in Section 4? It=E2=80=99s only a tangential remark. If it=E2=80=99s too much clutter, we= can remove it. https://github.com/lamps-wg/dilithium-certificates/pull/141 Section 10.2, para 2: I'd make first sentence about interoperability. The rest can be about why these two methods don't interoperate. Section 10.1, para 3: Let me summarize: HashML-DSA loses some hash collision protection, but it doesn't matter because of these other things? Did I understand that? If that's true, I'd soften the first sentence a bit. There is a security reason, but it isn't a strong one. The for realsie issue is interoperability (para 2). [note: IETF is all about interoperability, so making this the top reason is perfect.] We tweaked the text in https://github.com/lamps-wg/dilithium-certificates/pull/142 Section 10.1, Para 3: Is the hash of the public key referred to as 'tr'? If so, then 'hash of the public key tr' could be 'hash of the public key (tr)' [as is done with seed(xi)] Yes. Addressed in [1]. Appendices A-C: I did not review (other than noticing a typo). Appendix D, figure 2: I may very well be wrong (my math chops are gone), but shouldn't the mu computation include M? Assuming M is the message to be signed. (I see the hash of the pk, and ctx, but not M. I also see M' which I'm assuming is the hash of M in Figure 3). Happy to have you tell me I'm an idiot, and that it is correct. :) Viktor answered this already, and the correction of a different typo he spotted: https://github.com/lamps-wg/dilithium-certificates/pull/143 Appendix D: I would reiterate what ctx is suppose to be here. Addressed in [2] Nit: Section 10: spell out RBG (it is literally the only time it is used). Section C.4, warning: systmes/systems Addressed in [1]. Best, Bas [1] https://github.com/lamps-wg/dilithium-certificates/pull/137 [2] https://github.com/lamps-wg/dilithium-certificates/pull/138 On Fri, May 2, 2025 at 3:47=E2=80=AFPM Deb Cooley wr= ote: > Authors, > > Thank you for this well written draft. Below are my comments, some of > them are quite picky. I'm happy to chat about them. > > Deb > Sec AD > > ------------------------------------------- > Section 1.1: Is there a decent source for terminology? If so, list it > here. If there isn't, that's fine too. > > Section 2, algorithm: Nit: add (OID) after 'an object identifier'. > > Section 2, last sentence: ctx is not defined, nor used in the main part > of the draft, only in Appendix D. I would define it here. If it only > applies in the Appendix D situation, then I would move the statement (and > definition) there. > > Section 4: the ASN.1 is 'BIT STRING', the description is 'byte stream' o= r > 'byte string'. Is it worth making it clear that these are all the same > thing? I realize that the ASN.1 tags are fixed, but the explanatory text = is > not. ('OCTET STRING' is a whole other thing, so I'm leaving it out of th= is > comment) [I realize this is a ridiculously picky comment.] > > Section 8, last sentence: 'random seed xi' is called 'seed' or '32-byte > seed (xi)' everywhere else in the draft. Is it a loss of rigor to delete > the word 'random'? (also see my comment on Section 10) > > Section 10, para 3: I struggled with this paragraph. What's the point? > have you buried the lead? If the point is 'poor entropy', then I think > you lead with that. If the point is side channel protection, move that t= o > para 4? I think you can separate these two attack surfaces. In addition: > First two sentences: There are two modes, deterministic and randomized. > Second sentence is 'non-deterministic', change that to 'randomized'? > Sentence 3: there is a "private random seed (rho')" which I'm assuming is > a different value. Any chance we can reinforce that this is different fr= om > 'seed xi'? > throughout para 3: rnd, rng, spell them out. Clarify that the 256-bit > string is rnd. random for the randomized version and a constant string f= or > the deterministic version. I couldn't quite tell if 'rng' was a typo. > > Section 10, para 5: Meh.... the ability to export/lose control of a > private key leaves an issue with non-repudiation, no? I'm fine with the > paragraph as it stands, but add something to convey the risk of private k= ey > exposure. [I will note that I might also disagree with non-repudiation as= a > 'fundamental security property', but that is a personal bias.] > > Section 10, last sentence: 'These properties', which properties? The > properties in this section? Is this a security consideration? Or does i= t > belong up in Section 4? > > Section 10.2, para 2: I'd make first sentence about interoperability. > The rest can be about why these two methods don't interoperate. > > Section 10.1, para 3: Let me summarize: HashML-DSA loses some hash > collision protection, but it doesn't matter because of these other things= ? > Did I understand that? If that's true, I'd soften the first sentence a > bit. There is a security reason, but it isn't a strong one. The for > realsie issue is interoperability (para 2). [note: IETF is all about > interoperability, so making this the top reason is perfect.] > > Section 10.1, Para 3: Is the hash of the public key referred to as 'tr'? > If so, then 'hash of the public key tr' could be 'hash of the public key > (tr)' [as is done with seed(xi)] > > Appendices A-C: I did not review (other than noticing a typo). > > Appendix D, figure 2: I may very well be wrong (my math chops are gone), > but shouldn't the mu computation include M? Assuming M is the message to > be signed. (I see the hash of the pk, and ctx, but not M. I also see M' > which I'm assuming is the hash of M in Figure 3). Happy to have you tell > me I'm an idiot, and that it is correct. :) > > Appendix D: I would reiterate what ctx is suppose to be here. > > Nit: > Section 10: spell out RBG (it is literally the only time it is used). > Section C.4, warning: systmes/systems > --0000000000003418d90634382b8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Deb,

Thank you for your comm= ents.

Section 1.1:=C2=A0 Is there a dec= ent source for terminology?=C2=A0 If so, list

it here.= =C2=A0 If there isn't, that's fine too.


Perhaps PQUIP=E2= =80=99s pqc-engineers or hybrid-terminology comes closest, but it doesn=E2= =80=99t seem to be an ideal reference. Any terminology in particular you=E2= =80=99d like to see defined?


Section 2, algorithm:= Nit: add (OID) after 'an object identifier'.


Addressed in= [1].


Section 2, last sentence:=C2=A0 ctx is not d= efined, nor used in the main

part of the draft, only i= n Appendix D.=C2=A0 I would define it here.=C2=A0 If it

only applies in the Appendix D situation, then I would move the

statement (and definition) there.


It applies to the mai= n document. In [2] we make the reference more explicit.


Section 4:=C2=A0 the ASN.1 is 'BIT STRING', the description i= s 'byte

stream' or 'byte string'.=C2= =A0 Is it worth making it clear that these are

<= span style=3D"font-size:9pt;font-family:Arial,sans-serif;color:rgb(0,0,0);b= ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a= sian:normal;font-variant-alternates:normal;vertical-align:baseline">all the= same thing? I realize that the ASN.1 tags are fixed, but the

explanatory text is not.=C2=A0 ('OCTET STRING' is a whole o= ther thing, so

I'm leaving it out of this comment)= =C2=A0 [I realize this is a ridiculously

picky comment= .]


Does the change in [1] address this sufficiently?


=

Section 8, last sentence: 'random seed xi' is called = 9;seed' or

'32-byte seed (xi)' everywhere = else in the draft.=C2=A0 Is it a loss of

rigor to dele= te the word 'random'?=C2=A0 (also see my comment on Section<= /p>

10)


The =E2=80=9Crandom=E2=80=9D is meant to signal t= hat we=E2=80=99re in the case that the seed is randomly generated within th= e function, instead of being provided externally. What about making it an a= dverb on =E2=80=9Cgenerated=E2=80=9D as in [1]?


Se= ction 10, para 3:=C2=A0 I struggled with this paragraph. What's the

point?=C2=A0 have you buried the lead?=C2=A0 If the point= is 'poor entropy',

then I think you lead with= that.=C2=A0 If the point is side channel

protection, = move that to para 4? I think you can separate these two

attack surfaces.=C2=A0 In addition:

First two senten= ces:=C2=A0 There are two modes, deterministic and

rand= omized.=C2=A0 Second sentence is 'non-deterministic', change that t= o

'randomized'?

Sentence = 3: there is a "private random seed (rho')" which I'm assu= ming

is a different value.=C2=A0 Any chance we can rei= nforce that this is

different from 'seed xi'?<= /span>

throughout para 3:=C2=A0 rnd, rng, spell them out.=C2= =A0 Clarify that the

256-bit string is rnd.=C2=A0 rand= om for the randomized version and a

constant string f= or the deterministic version.=C2=A0 I couldn't quite tell

if 'rng' was a typo.


In https://github.com/lamps-wg/dilithium-certificates/pul= l/139 we moved and tightened up the section. Does this work for you?


Section 10, para 5:=C2=A0 Meh.... the ability to ex= port/lose control of a

private key leaves an issue wit= h non-repudiation, no?=C2=A0 I'm fine with

<= span style=3D"font-size:9pt;font-family:Arial,sans-serif;color:rgb(0,0,0);b= ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a= sian:normal;font-variant-alternates:normal;vertical-align:baseline">the par= agraph as it stands, but add something to convey the risk of

private key exposure. [I will note that I might also disagree with

non-repudiation as a 'fundamental security property= ', but that is a

personal bias.]


We tweake= d the wording. https://gith= ub.com/lamps-wg/dilithium-certificates/pull/140


Section 10, last sentence: 'These properties', which properties?= =C2=A0 The

properties in this section?=C2=A0 Is this a= security consideration?=C2=A0 Or

does it belong up in= Section 4?


It=E2=80=99s only a tangential remark. If it=E2=80=99s = too much clutter, we can remove it. https://github.com/lamps-wg/dilithium-certificates/pull/141=


Section 10.2, para 2:=C2=A0 I'd make first sente= nce about interoperability.

The rest can be about why = these two methods don't interoperate.


Section = 10.1, para 3:=C2=A0 Let me summarize:=C2=A0 HashML-DSA loses some hash

collision protection, but it doesn't matter because of= these other

things?=C2=A0 Did I understand that?=C2= =A0 If that's true, I'd soften the first

sente= nce a bit. There is a security reason, but it isn't a strong one.

The for realsie issue is interoperability (para 2). [note:= =C2=A0 IETF is

all about interoperability, so making t= his the top reason is perfect.]


We tweaked the text in https://github.com/lamps-wg/dilithium-c= ertificates/pull/142


Section 10.1, Para 3:=C2= =A0 Is the hash of the public key referred to as

'= tr'?=C2=A0 If so, then 'hash of the public key tr' could be = 9;hash of the

public key (tr)'=C2=A0 [as is done w= ith seed(xi)]


Yes. Addressed in [1].


Appen= dices A-C:=C2=A0 I did not review (other than noticing a typo).

<= br>

Appendix D, figure 2:=C2=A0 I may very well be wrong (my math= chops are

gone), but shouldn't the mu computation= include M?=C2=A0 Assuming M is the

message to be sig= ned. (I see the hash of the pk, and ctx, but not M.

I = also see M' which I'm assuming is the hash of M in Figure 3).=C2=A0= Happy

to have you tell me I'm an idiot, and that = it is correct.=C2=A0 :)


Viktor answered this already, and the corre= ction of a different typo he spotted: https://github.com/lamps-wg/dilithium-certificates/pull/143


Appendix D:=C2=A0 I would reiterate what ctx is su= ppose to be here.


Addressed in [2]


<= span style=3D"font-size:9pt;font-family:Arial,sans-serif;color:rgb(0,0,0);b= ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a= sian:normal;font-variant-alternates:normal;vertical-align:baseline">Nit:

Section 10:=C2=A0 spell out RBG (it is literally the onl= y time it is used).

Section C.4, warning:=C2=A0 systme= s/systems


Addressed in [1].


Best,


Bas


[1] <= span style=3D"font-size:9pt;font-family:Arial,sans-serif;background-color:t= ransparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-= variant-alternates:normal;text-decoration-line:underline;vertical-align:bas= eline">https://github.com/lamps-wg/dilithium-certificates/pull/137

= [2] https://github.com/lamp= s-wg/dilithium-certificates/pull/138




On Fri, M= ay 2, 2025 at 3:47=E2=80=AFPM Deb Cooley <debcooley1@gmail.com> wrote:
Authors,

Thank you for this well written draft.=C2=A0 Below are my c= omments, some of them are quite picky.=C2=A0 I'm happy to chat about th= em.

Deb
Sec AD

=
-------------------------------------------
Section 1.1: =C2= =A0Is there a decent source for terminology?=C2=A0 If so, list it here.=C2= =A0 If there isn't, that's fine too.

Section 2, algorithm:= Nit: add (OID) after 'an object identifier'.

Section 2, las= t sentence: =C2=A0ctx is not defined, nor used in the main part of the draf= t, only in Appendix D.=C2=A0 I would define it here.=C2=A0 If it only appli= es in the Appendix D situation, then I would move the statement (and defini= tion) there.

Section 4: =C2=A0the ASN.1 is 'BIT STRING', the= description is 'byte stream' or 'byte string'.=C2=A0 Is it= worth making it clear that these are all the same thing? I realize that th= e ASN.1 tags are fixed, but the explanatory text is not. =C2=A0('OCTET = STRING' is a whole other thing, so I'm leaving it out of this comme= nt) =C2=A0[I realize this is a ridiculously picky comment.]

Section = 8, last sentence: 'random seed xi' is called 'seed' or '= ;32-byte seed (xi)' everywhere else in the draft.=C2=A0 Is it a loss of= rigor to delete the word 'random'? =C2=A0(also see my comment on S= ection 10)

Section 10, para 3: =C2=A0I struggled with this paragraph= . What's the point? =C2=A0have you buried the lead?=C2=A0 If the point = is 'poor entropy', then I think you lead with that.=C2=A0 If the po= int is side channel protection, move that to para 4? I think you can separa= te these two attack surfaces.=C2=A0 In addition:
First two sentences: = =C2=A0There are two modes, deterministic and randomized.=C2=A0 Second sente= nce is 'non-deterministic', change that to 'randomized'? Sentence 3: there is a "private random seed (rho')" which I= 'm assuming is a different value.=C2=A0 Any chance we can reinforce tha= t this is different from 'seed xi'?
throughout para 3: =C2=A0rn= d, rng, spell them out.=C2=A0 Clarify that the 256-bit string is rnd. =C2= =A0random for the randomized version and a constant string for the determin= istic version.=C2=A0 I couldn't quite tell if 'rng' was a typo.=

Section 10, para 5: =C2=A0Meh.... the ability to export/lose contro= l of a private key leaves an issue with non-repudiation, no?=C2=A0 I'm = fine with the paragraph as it stands, but add something to convey the risk = of private key exposure. [I will note that I might also disagree with non-r= epudiation as a 'fundamental security property', but that is a pers= onal bias.]

Section 10, last sentence: 'These properties', w= hich properties?=C2=A0 The properties in this section?=C2=A0 Is this a secu= rity consideration?=C2=A0 Or does it belong up in Section 4?

Section= 10.2, para 2: =C2=A0I'd make first sentence about interoperability.=C2= =A0 The rest can be about why these two methods don't interoperate.
=
Section 10.1, para 3: =C2=A0Let me summarize: =C2=A0HashML-DSA loses so= me hash collision protection, but it doesn't matter because of these ot= her things?=C2=A0 Did I understand that?=C2=A0 If that's true, I'd = soften the first sentence a bit. There is a security reason, but it isn'= ;t a strong one.=C2=A0 The for realsie issue is interoperability (para 2). = [note: =C2=A0IETF is all about interoperability, so making this the top rea= son is perfect.]

Section 10.1, Para 3: =C2=A0Is the hash of the publ= ic key referred to as 'tr'?=C2=A0 If so, then 'hash of the publ= ic key tr' could be 'hash of the public key (tr)' =C2=A0[as is = done with seed(xi)]

Appendices A-C: =C2=A0I did not review (other th= an noticing a typo).

Appendix D, figure 2: =C2=A0I may very well be = wrong (my math chops are gone), but shouldn't the mu computation includ= e M?=C2=A0 Assuming M is the message to be signed. (I see the hash of the p= k, and ctx, but not M.=C2=A0 I also see M' which I'm assuming is th= e hash of M in Figure 3).=C2=A0 Happy to have you tell me I'm an idiot,= and that it is correct. =C2=A0:)

Appendix D: =C2=A0I would reiterat= e what ctx is suppose to be here.

Nit: =C2=A0
Section 10: =C2=A0s= pell out RBG (it is literally the only time it is used).
Section C.4, wa= rning: =C2=A0systmes/systems
--0000000000003418d90634382b8c--