Last Call Review of draft-jones-cose-rsa-03
review-jones-cose-rsa-03-secdir-lc-kent-2017-06-02-00

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.