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

[Orie <orie@xxxxxxx>]

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 <noreply@xxxxxxxx> 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. 

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx