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

[Mike Jones <[e-mail]>]

https://tools.ietf.org/html/draft-jones-cose-rsa-04 contains the changes we discussed, Steve.  Thanks again for the useful review!



                                                                -- Mike



P.S.  I also thanked you in the publication announcement at http://self-issued.info/?p=1697 and as @selfissued<https://twitter.com/selfissued>.


From: Steve KENT [mailto:[e-mail]]
Sent: Saturday, June 3, 2017 7:36 AM
To: Mike Jones <[e-mail]>; [e-mail]
Cc: Kathleen Moriarty <[e-mail]>
Subject: Re: SECDIR review of draft-ietf-jones-cose-rsa-03


Mike,



I think the text you cited re "trust criteria" is good.



Yes, let's see what the CFRG suggests re a reference.



deleting the last sentence in 6.3 work for me.



Steve

________________________________
From: Mike Jones <[e-mail]<mailto:[e-mail]>>
Sent: Friday, June 2, 2017 4:14:28 PM
To: Steve KENT; [e-mail]<mailto:[e-mail]>
Cc: Kathleen Moriarty
Subject: RE: SECDIR review of draft-ietf-jones-cose-rsa-03

Thanks for your useful review, Steve.  Replies are inline below...

From: Steve KENT [mailto:[e-mail]]
Sent: Tuesday, May 30, 2017 8:34 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Mike Jones <[e-mail]<mailto:[e-mail]>>; Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>
Subject: SECDIR review of draft-ietf-jones-cose-rsa-03


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.

Rather than talking about "legitimate participants", how about I instead talk about "parties trusted by the recipient" or possibly "after making a trust decision about the key"?  The notion is that you should only perform crypto after making a trust decision about the key.  This concept is further spelled out in Appendix D (Notes on Key Selection) of RFC 7515 (https://tools.ietf.org/html/rfc7515#appendix-D)  as:
   4.  Make trust decisions about the keys.  Signatures made with keys
       not meeting the application's trust criteria would not be
       accepted.  Such criteria might include, but is not limited to,
       the source of the key, whether the TLS certificate validates for
       keys retrieved from URLs, whether a key in an X.509 certificate
       is backed by a valid certificate chain, and other information
       known by the application.


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.



I've asked the CFRG for a reference.  We'll see what they come up with.



I'm thinking that it might also be valuable to add this Security Considerations text about RSASSA-PSS from Section 8.3 of RFC 7518 (https://tools.ietf.org/html/rfc7518#section-8.3):



   Keys used with RSAES-PKCS1-v1_5 must follow the constraints in

   Section 7.2 of RFC 3447<https://tools.ietf.org/html/rfc3447#section-7.2>.  Also, keys with a low public key exponent

   value, as described in Section 3<https://tools.ietf.org/html/rfc7518#section-3> of "Twenty Years of Attacks on the

   RSA Cryptosystem" [Boneh99<https://tools.ietf.org/html/rfc7518#ref-Boneh99>], must not be used.



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.

I'm actually thinking that that this sentence should just be deleted, as I doubt that any supporting references can be found - for the simple reason that you typically can't prove a negative, nor would anybody likely publish saying "There are no practical attacks yet."  Since researchers wouldn't publish this, I probably shouldn't say it in an RFC either.

                                                                Thanks again,
                                                                -- Mike