Subject: [secdir] SECDIR review of draft-ietf-jones-cose-rsa-03

From: Steve KENT <[email-masked]>
Date: Tue, 30 May 2017 15:38:05 +0000

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 with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines algorithm encodings and representations for using RSA algorithms in the context of COSE messages (draft-ietf-cose-msg).  Encodings for the use of RSASSA-PSS signatures, RSAES-OAEP encryption, and RSA keys are specified in this document.

This is a very brief document, only 8 pages, including the usual RFC boilerplate. Most of the document consists of tables specifying the numeric values assigned to RSA algorithms (and parameters thereof) used for encryption and signing in the COSE message context.

Section 2 defines the parameters for RSASSA-PSS, appropriately citing RFC 3447. Section 3 provides analogous specs for RSAES-OAEP.

Section 4 defines RSA key pair parameter identifiers, including  support for multi-prime RSA keys, based on conventions described in RFC 3447.

Security Considerations are the topic of Section 6. Section 6.1 establishes 2K bit keys as a minimum SHOULD size, but also establishes 16K keys as a maximum SHOULD. The text notes that very large keys create a possible DoS attack surface, and it suggests (lower case “recommend”) that a size check be performed before beginning crypto operations. The final paragraph of this subsection includes text that does not seems very useful, as it is too vague. Specifically it says “…no cryptography would be done except with keys of legitimate parties.” The term “legitimate” is too vague to be useful. Does it mean that only keys extracted from verified public key certificates or acquired through trusted channels are to be employed? The second countermeasure noted here, i.e., that applications can specified maximum as well as minimum key sizes, seems much more useful.

Section 6.2 opens with the following statement: “There is a theoretical hash substitution attack that can be mounted against RSASSA-PSS.” This sentence should include a reference to a paper that describes this attack. Similarly, the closing sentence of Section 6.3 also would benefit from a reference to a paper that supports the author’s assertion that using SHA-1 in this context does not enable any (known) attacks.