[COSE] Re: draft-ietf-cose-dilithium-08 ietf last call Secdir review

[Orie <[e-mail]>]

Hi Peter,

Thank you for your review.

I've raised https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/23

Please let me know if you have any additional suggestions to improve this
document.

See inline comments for your specific points.

Regards,

OS

On Sat, Aug 16, 2025 at 10:02 PM Peter Yee via Datatracker <[e-mail]>
wrote:

> Document: draft-ietf-cose-dilithium
> Title: ML-DSA for JOSE and COSE
> Reviewer: Peter Yee
> Review result: Has Issues
>
> Reviewer: Peter Yee
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments
> were written primarily for the benefit of the security area directors.
> Document
> editors and WG chairs should treat these comments just like any other last
> call
> comments.
>
> Summary: This document adds IANA registrations and support for the ML-DSA
> algorithm to both JOSE and COSE. It’s mostly straightforward material with
> reasonable pointers into FIPS 204, but it has a couple of areas I’d like
> to see
> explained better and a few harmless nits that could be fixed.
>
> The summary of the review is Has Issues.
>
> Major issues: None
>
> Minor issues:
>
> Page 8, section 7.1: I don’t see how this is really a security
> consideration.
> It’s an operational consideration to be sure.
>

I moved this section out.


>
> Page 8, section 7.2: Is this meant to intimate that HashML-DSA is not
> desirable? Or that you’ve merely declined to specify such algorithms? I’m
> not
> sure the sentence adds much as FIPS 204 already says, “…the digest that is
> signed needs to be generated using an approved hash function or XOF (e.g.,
> from
> FIPS 180 [8] or FIPS 202 [7]) that provides at least 𝜆 bits of classical
> security strength against both collision and second preimage attacks”.
>

I added some elaboration and reference to
https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/which
has more language relevant to the decision to not register algorithm
identifiers for HashML-DSA.


>
> Page 8, section 7.3, 2nd paragraph, 2nd sentence: What does “validated”
> mean
> here? Looking at FIPS 204, Algorithms 22 and 23 (pkEncode and pkDecode) are
> format translators. I don’t see mention of validation, and neither
> algorithm
> returns a status as part of the specified steps. If you mean that the
> inputs
> are within the ranges given for the inputs, then say that.
>
>
I've taken your suggested framing.


> Nits:
>
> Page 4, Figure 1 caption: change “all zeroes” to “all-zeroes”. Same for
> Figure
> 2.
>
> Page 8, section 7, 1st paragraph: Append a comma after “[RFC7517]”.
>
> Page 8, section 7.3, 1st paragraph: change “algorithm related” to
> “algorithm-related”.
>
> Page 9, section 8.1.1, 2nd sentence: Change “RFC9053” to “RFC 9053” and
> “RFC9054” to “RFC 9054”. See RFC 7322, section 3.5.
>
> Page 10, section 8.1.2, 2nd sentence: Change “RFC9053” to “RFC 9053”.
>
> Page 10, section 8.1.3, 2nd sentence: Change “RFC9053” to “RFC 9053”.
>
> Page 11, section 8.1.4, 2nd sentence: Change “RFC7518” to “RFC 7518”.
>
> Page 12, section 8.1.5, 2nd sentence: Change “RFC7518 RFC7638” to “RFC
> 7518 and
> RFC 7638”.
>
> Page 13, section 8.1.6, 2nd sentence: Change “RFC7517” to “RFC 7517” and
> “RFC7638” to “RFC 7638. Elide the comma.
>

Thank you for these nits, I believe I got them all.

>
> Page 15: the text version of the document has really confused page numbers
> in
> the Appendix. I’m not sure there’s much to be done for that, but it makes
> for
> an odd table of contents that makes one think the examples are a page each
> and
> the document in total is 17 pages. In text format, it really takes up 50
> “printed” pages.
>

I suspect this is due to the examples, I am not sure what to do about this,
but thanks for your patience in reviewing the document.


>
> I have not made any attempt to review Appendix A as I lack the ready
> capability
> to do so.
>

Acknowledged.