Thanks for the useful review, Charlie. Responses and proposed resolutions follow inline. Working group - please review.
From: Charlie Kaufman [mailto:[email protected]] Sent: Saturday, August 30, 2014 12:12 AM To: [email protected] Cc: [email protected]; [email protected] Subject: Secdir review of draft-ietf-jose-json-web-algorithms-31 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. This document sets the initial IANA registry values for the labels to be used to specify choices of cryptographic algorithms in the context of the JSON Web Encryption, JSON Web Signature, and JSON Web Key documents (parallel I-Ds). Some aspects of how the algorithms are used are specified here; others aspects reference other documents. The issues I found with this document (all of which are minor): Section 3.4 line 4 says Elliptic Curves are generally faster to execute (for equivalent security) than RSA. While that is true for private key operations (and even more dramatically so for key generation), it is generally not true for public key operations. This is a nit in the text since these trade-offs are well understood. What if we were to change the phrase "with greater processing speed" to "with greater processing speed for many operations"? Section 4.5 Direct Encryption: It might be too late to change existing implementations, but it generally a good idea when using pre-negotiated keys to include some key identifier in the header to remove ambiguity in the case where there are multiple pre-negotiated keys (perhaps because they are in the process of being updated and they are not atomically updated on both ends of the connection). The "kid" (Key ID) header parameter defined in the JWE spec already enables this to be done. Section 5.1: I don't believe the pairings of AES128/HMAC-SHA256, AES192/HMAC-SHA384, and AES256/HMAC-SHA512 are "natural" in the sense of providing equivalent cryptographic strength. Without the HMAC, they would, but I believe HMAC-SHA256 is generally believed to have 256 bits of cryptographic strength, making it suitable for pairing with any of the three AES key sizes. The choices of the longer SHA2 variants are conservative, however, and so do no harm if these pairings are already in widespread use. They are in use and are the pairings chosen by David McGrew, a just departed CRFG chair, and Kenny Paterson, a current CRFG chair, in draft-mcgrew-aead-aes-cbc-hmac-sha2. Section 5.2: Similarly, it is not appropriate to have the length of the Message Authentication Code (MAC) reflect the key length, since it does not affect cryptographic strength but rather the strength against on-line MAC guessing attacks. For this purpose, 128 bits is generally considered adequate for all key sizes and many implementations truncate this to 96 bits or even 64. Again, the current specification is conservative (if slightly wasteful of bandwidth), and so does not harm if this is already in widespread use. (Same answer as to the previous comment) Section 5.2.2.1 says "The number of octets in the input key K is the sum of MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say something like "MUST BE the sum". The text goes on to say that the two keys must not overlap, but it is also important that an implementation not tolerate a gap between the two keys is a too large key is provided. OK Section 5.2.2.2 says the authenticated decryption operation has four inputs... . I believe it has a fifth: the IV. Alternately, the IV is pre-pended to the ciphertext (and hence implicitly included in 'E'). Agreed the IV is a fifth input. I'll make this change. Section 5.3 specifies AES/GCM in much less detail than the description of AES/HMAC in Section 5.2. Is this because the referenced document [NIST.800-38D] includes all the needed details (like use of PKCS7 padding)? Yes Section 6.2.1.1: Because of the controversy over NSA allegedly planting backdoors in the "NIST curves" listed, there is a growing demand that additional curves be supported. You might want to specify how additional curves can be specified in-line and/or how to get additional curves added to the IANA registry. Agreed. We can tweak the IANA language in this section (and possibly others using similar language) to be clearer on this point. Section 8.7: I believe the advice in this section is too strong. It is generally considered secure to encrypt multiple data sets with the same key so long as the IV is correctly chosen and it is also generally considered secure to encrypt the same data set with multiple different keys. There are many scenarios in which this is nearly impossible to avoid. It is important that when encryption multiple data sets with the same key that the IV be chosen appropriately - which is very challenging when using GCM as noted in section 8.4. The current language was added to resolve issue #28 http://trac.tools.ietf.org/wg/jose/trac/ticket/28 and is a result of a good bit of discussion with Michael Peck, Jim Schaad, and others in the working group on the JOSE mailing list between June 2013 and August 2013, with the issue being closed by Jim in October 2013. I recognize that of the problem here is that the security considerations actually vary by algorithm and yet this subsection is trying to provide general guidance. Is there a specific wording change that you'd like to propose that would weaken the advice when it's OK to weaken it, but not in any other circumstances? Section 8.8: I believe the advice in this section is too weak. It is generally bad practice to derive cryptographic keys from passwords as passwords almost never have adequate entropy. Where possible, it would be better to have a strong (i.e. randomly chosen) cryptographic key associated with an entity and then use the password to acquire that cryptographic key. There are a number of means for doing that, including having the strong key encrypted with the password (or XORed with it) stored someplace the entity can access it, by having a server that will return the key based on a provided password, or with a strong password authentication protocol. Deriving the key from a password using PBES should be a last resort and demanding a longer password to derive a 256 bit key is only fooling yourself... you are never likely to get more than 64 bits of entropy. Note that password-based encryption, as used by this specification, does employ a randomly chosen content encryption key, and uses the password-based encryption only to encrypt the CEK. Does that alleviate your concerns? If not, could you supply specific proposed wording changes that would? --Charlie Thanks again, -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
