[lamps] Re: AD comments on draft-ietf-lamps-dilithium-certificates

[Bas Westerbaan <[e-mail]>]

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’s pqc-engineers or hybrid-terminology comes closest, but it
doesn’t seem to be an ideal reference. Any terminology in particular you’d
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 “random” is meant to signal that we’re in the case that the seed is
randomly generated within the function, instead of being provided
externally. What about making it an adverb on “generated” 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’s only a tangential remark. If it’s 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 PM Deb Cooley <[e-mail]> 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 (and
> 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 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.]
>
> 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 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.
>
> 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.]
>
> 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 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
>