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

[Deb Cooley <[e-mail]>]

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 AM Bas Westerbaan <[e-mail]> 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’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
>>
>