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 BE6CA246394C; Sat, 3 May 2025 03:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 9aAgziZ4Qpe0; Sat, 3 May 2025 03:54:23 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 A18002463945; Sat, 3 May 2025 03:54:23 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-22435603572so35961245ad.1; Sat, 03 May 2025 03:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746269663; x=1746874463; 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=zkhJTR1bWFTSUTxX6FSLO+jv4gPjYsYUyTqnNtLDh0g=; b=ZYW+5dcVXnuPJam+hMkFwuIW3KKnq691AkKtIQOX/A03rGrW4v5d1YL3nY6shL5X0y 0/hhgH3EFSMnvBLwCgDmo8oEWjfMS/YKCzPs3j1AE5TQyZZxfiunMLf5Z3SGtVgAw3s9 1XL1lo8dBzC+39Z2LbJ4v6v6lfd6aQVobCJyiqkzL3aL64ptIgRtz+HiIy873TjeMUpX HD1V+9UXcGDFh3Irep9AFQn9IYdr+P5kjQOXuqfeLXAnQ2sTyZ10rbZxR4JYtBr5sPId HAYMJNYFo71dMogQMtYcKlKeevoZ5JoTrCwcfGHfbGZPRJhtmf/8imAhnPd2iUKGIfq1 wpoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746269663; x=1746874463; 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=zkhJTR1bWFTSUTxX6FSLO+jv4gPjYsYUyTqnNtLDh0g=; b=V3l55Harrad2y7BRGpywPLurImop9aFE8sjvvZb0OzkpHJvM4adXCEYhUQI0Six3vo xwcBCeQBQSHUpF6jYZC14k0V8rzuth/FTvfJhWxtY0tcDf8FpENXoi5ZBrOQpuzRLz3Y edCYJQUJdg+31TTe4+qk/gpcxNo6Yk+Symj96W8uAaAlv7MqMVcTlagPerOwl10zkaJZ d7C3joMw5T56ALIM6ANy3JqWgniLmHrwZQRqym5C34O3ltXKBS9a1eIFq3Ntmkmlnt1Z DH02ddTCLuQsFJ53ET3lY0XJ/B/E6iibyE7Tvr90C+eA/hp7p2tPniWEkNHUIsG6TDVk fftw== X-Forwarded-Encrypted: i=1; AJvYcCW698AAcbLha0W0RO020EUmeELA0oewvu7l2WPFQDyX3vgvIYqGYAESCW7qeIDqcoYXLS/9+2JDHs77ggydg/g5YtUfyPh3xEfIgeLx5Fh0kJh47ZTK+mNB+9SxYnByZw==@ietf.org, AJvYcCXncWt5Tvp4MoJYrVDPhJahmDecqZZXL4pisEBDK7V9ave/+dg/8Xs6simQeyl+QHYSpyugsk9hWlHA0Iv6@ietf.org X-Gm-Message-State: AOJu0YwIjmTE7BwOG6VMTKvnlZAkW/27IhhLysLPK4F2ZvBN6HTEEOB0 uCMkjtDQy8ADIerAIrk97yJwR9+JcoZEm1fhC7q/1H/1Al0ziGfvGsUc13qcWvQ2zaatxpwqCjh FtlOsWVPrRaUslltrdGyvZ7NAag== X-Gm-Gg: ASbGncs4odsl/0fc50USeW7wpqGqIAGiKUHNMLRkERgZTH8S760FoclULVoe/2K+bnX F+gvj1SVyLKXo1JQvdIglbsZp/xuJoH9ho5ZdnZwOypIMmggJJm2X2m8gwo8sWm5/0/702osjUn RY0zYHlS8NAN1IE+HRluRiq9vrqJQRSBkkF9BEqYGTHDTqRNSK09/ch5A= X-Google-Smtp-Source: AGHT+IG2irlMZaYF4mumBM3KQcb+MP+0jcx/1DnLUTv35hye+ikmiGR2v/UsErSbqFQKSDJ6ds57Hb+eTpJGlCaZpCo= X-Received: by 2002:a17:90b:3d84:b0:2ee:ab29:1a63 with SMTP id 98e67ed59e1d1-30a61957f3dmr957699a91.3.1746269662328; Sat, 03 May 2025 03:54:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Deb Cooley Date: Sat, 3 May 2025 06:54:10 -0400 X-Gm-Features: ATxdqUGP_2N9eyrqzSGOjTEU4NKsPVZTq4rylZExKVwk6fSO2XYRCA-kX-7zeCU Message-ID: To: Bas Westerbaan Content-Type: multipart/alternative; boundary="000000000000e7bddd06343916a2" Message-ID-Hash: HN25S2QUQQGL5FFUA3GMQVD5PB6QXX53 X-Message-ID-Hash: HN25S2QUQQGL5FFUA3GMQVD5PB6QXX53 X-MailFrom: debcooley1@gmail.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: --000000000000e7bddd06343916a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the quick work. These all look good. If you send me a full diff before you push a version update, I can do one last check. (watch the long lines, which apparently get truncated in the html version) Deb On Sat, May 3, 2025 at 5:48=E2=80=AFAM Bas Westerbaan = wrote: > 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 particu= lar 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= case 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= as 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 = wrote: > >> 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 (an= d >> definition) there. >> >> 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 sa= me >> 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 t= his >> 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 delet= e >> 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 = 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 i= s >> a different value. Any chance we can reinforce that this is different f= rom >> '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. >> >> 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 a= s 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 = it >> 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 thing= s? >> 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 pub= lic >> 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 t= o >> 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 tel= l >> 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 >> > --000000000000e7bddd06343916a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick work.=C2=A0 These all look good.= =C2=A0

If you send me a full diff before you = push a version update, I can do one last check.=C2=A0 (watch the long lines= , which apparently get truncated in the html version)

<= div>Deb

On Sat, May 3, 2025 at 5:48=E2=80=AFAM B= as Westerbaan <bas@cloudflare.com<= /a>> wrote:
<= div dir=3D"ltr">
Deb,

Thank you for your comme= nts.

Section 1.1:= =C2=A0 Is there a decent 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?


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


Addressed in [1].


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

part of t= he draft, only in Appendix D.=C2=A0 I would define it here.=C2=A0 If it

only applies in the Appendix D situation, then I would mo= ve the

statement (and definition) there.

It ap= plies to the main document. In [2] we make the reference more explicit.


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

stream' or 'byte s= tring'.=C2=A0 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.=C2=A0 ('OCTET STRING'= ; is a whole other 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?<= /span>


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

'32-byte seed (xi)= 9; 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)


The =E2=80=9Crandom=E2=80=9D is mea= nt to signal that we=E2=80=99re in the case that the seed is randomly gener= ated within the function, instead of being provided externally. What about = making it an adverb on =E2=80=9Cgenerated=E2=80=9D as in [1]?

Section 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 th= ink 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 sentences:=C2=A0 There are two modes, deterministic and

randomized.=C2=A0 Second sentence is 'non-deterministic= 9;, change that to

'randomized'?

Sentence 3: there is a "private random seed (rho')" w= hich I'm assuming

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

different from &#= 39;seed xi'?

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

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

co= nstant string for the deterministic version.=C2=A0 I couldn't quite tel= l

if 'rng' was a typo.


In https://github.com/la= mps-wg/dilithium-certificates/pull/139 we moved and tightened up the s= ection. Does this work for you?


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

private key leaves an issue with non-repudiation, no?=C2=A0 I'm fi= ne with

the paragraph as it stands, but add something = to convey the risk of

private key exposure. [I will no= te that I might also disagree with

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

personal bias.]


We tweaked the wording. https://github.com/lamps-wg/dil= ithium-certificates/pull/140


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

properties in this section?=C2=A0 Is this a security considerat= ion?=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. <= 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/141


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

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


Section 1= 0.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

sentence= 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 this= the top reason is perfect.]


We tweaked the text in https://github.com/lamp= s-wg/dilithium-certificates/pull/142


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

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-left:36pt;margin-top:0pt;mar= gin-bottom:0pt">'tr'?=C2=A0 If so, then 'hash of the public key tr= 9; could be 'hash of the

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


Yes. Addressed in [1].

Appendices A-C:=C2=A0 I did not review (other than noticing a t= ypo).


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

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

m= essage to be signed. (I see the hash of the pk, and ctx, but not M.<= /p>

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 alrea= dy, and the correction of a different typo he spotted: https://github.com/lamps-wg/d= ilithium-certificates/pull/143


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


Addressed in= [2]


Nit:

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

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


Addressed in [1].=


Best,


Bas

[1] <= /span>https://gi= thub.com/lamps-wg/dilithium-certificates/pull/137

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


<= br>

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

Thank you for this well writt= en draft.=C2=A0 Below are my comments, some of them are quite picky.=C2=A0 = I'm happy to chat about them.

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.<= /div>
Section 2, algorithm: Nit: add (OID) after 'an object identifi= er'.

Section 2, last sentence: =C2=A0ctx is not defined, nor use= d in the main part of the draft, only in Appendix D.=C2=A0 I would define i= t here.=C2=A0 If it only applies in the Appendix D situation, then I would = move the statement (and definition) 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 the ASN.1 tags are fixed, but the explanatory t= ext is not. =C2=A0('OCTET STRING' is a whole other thing, so I'= m leaving it out of this comment) =C2=A0[I realize this is a ridiculously p= icky comment.]

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

Section 10, para 3: =C2=A0= I struggled with this paragraph. What's the point? =C2=A0have you burie= d 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 addit= ion:
First two sentences: =C2=A0There are two modes, deterministic and= randomized.=C2=A0 Second sentence is 'non-deterministic', change t= hat to 'randomized'?
Sentence 3: there is a "private rando= m seed (rho')" which I'm assuming is a different value.=C2=A0 = Any chance we can reinforce that this is different from 'seed xi'?<= br> throughout para 3: =C2=A0rnd, rng, spell them out.=C2=A0 Clarify that t= he 256-bit string is rnd. =C2=A0random for the randomized version and a con= stant string for the deterministic version.=C2=A0 I couldn't quite tell= if 'rng' was a typo.

Section 10, para 5: =C2=A0Meh.... the = ability to export/lose control of a private key leaves an issue with non-re= pudiation, 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 m= ight also disagree with non-repudiation as a 'fundamental security prop= erty', but that is a personal bias.]

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?

Section 10.2, para 2: =C2=A0I'd make first senten= ce about interoperability.=C2=A0 The rest can be about why these two method= s don't interoperate.

Section 10.1, para 3: =C2=A0Let me summari= ze: =C2=A0HashML-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 sentence a bit. There is a se= curity reason, but it isn't a strong one.=C2=A0 The for realsie issue i= s interoperability (para 2). [note: =C2=A0IETF is all about interoperabilit= y, so making this the top reason is perfect.]

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

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

Appendix D, figure= 2: =C2=A0I may very well be wrong (my math chops are gone), but shouldn= 9;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.=C2=A0 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:)

Appen= dix D: =C2=A0I would reiterate what ctx is suppose to be here.

Nit: = =C2=A0
Section 10: =C2=A0spell out RBG (it is literally the only time it= is used).
Section C.4, warning: =C2=A0systmes/systems
--000000000000e7bddd06343916a2--