Subject: [OAUTH-WG] FW: Proposed Security Considerations sections changes

From: Mike Jones <[email-masked]>
Date: Tue, 10 Jun 2014 00:34:19 +0000

Also forwarding this to the OAuth WG, given Kathleen's comments on the JWT security considerations section.  (However, please conduct discussions about the JOSE text on the [email-masked]<mailto:[email-masked]> list and only reply here if you are proposing a change to the JWT security considerations section.)

                                                                -- Mike

From: Mike Jones
Sent: Monday, June 09, 2014 5:32 PM
To: [email-masked]
Cc: Kathleen Moriarty
Subject: Proposed Security Considerations sections changes

In response to Kathleen's requests to beef up the security considerations sections, I propose the following 9 actions:

1.  In the JWE spec, add the heading "11.1. Adaptive Chosen-Ciphertext Attacks" before the Security Considerations text beginning:
   When decrypting, particular care must be taken not to allow the JWE
   recipient to be used as an oracle for decrypting messages.

2.  At the end of the JWE Security Considerations, add the text:

   11.2. Timing Attacks

   To mitigate the timing attacks described in RFC 3218<http://tools.ietf.org/html/rfc3218> [RFC3218<http://tools.ietf.org/html/rfc3218>], the

   recipient MUST NOT distinguish between format, padding, and

   length errors of encrypted keys.  It is strongly recommended, in

   the event of receiving an improperly formatted key, that the

   receiver substitute a randomly generated CEK and proceed to the

   next step, to mitigate timing attacks.

3.  Remove the text from step 2 above from the place it occurs earlier (in JWE Section 5.2, step 10), and instead reference the security considerations text there.

4.  Add JWA Security Considerations subsections on "Adaptive Chosen-Ciphertext Attacks" and "Timing Attacks", which reference the JWE subsections (rather duplicating the text in JWA).

5.  In the JWK spec, add the heading "8.1. Key Provenance and Trust" before the security considerations text beginning:

   One should place no more trust in the data associated with a key than

   in than the method by which it was obtained and in the

   trustworthiness of the entity asserting an association with the key.

6.  In the JWK spec, add the heading "8.2. Preventing Disclosure of Non-Public Key Information" before the security considerations text beginning:
  Private and symmetric keys MUST be protected from disclosure to

  unintended parties.

7.  In the JWK spec, replace the current text citing XML DSIG 2.0 with the following and move it into the Key Provenance and Trust section:

   The security considerations in Section 12.3 of XML DSIG 2.0

   [W3C.NOTE-xmldsig-core2-20130411<http://tools.ietf.org/html/draft-ietf-jose-json-web-key-26#ref-W3C.NOTE-xmldsig-core2-20130411>], about the strength of a signature

   depending upon all links in the security chain also apply

   to this specification.

8.  In the JWK spec, add the new security considerations text:
   11.2. RSA Private Key Representations and Blinding

   The RSA Key blinding operation [Kocher], which is a defense

   against some timing attacks, requires all of the

   RSA key values "n", "e", and "d".  However,

   some RSA private key representations do not include the

   public exponent "e", but only include the modulus "n"

   and the private exponent "d".  This is true, for instance,

   of the Java RSAPrivateKeySpec API, which does not include

   the public exponent "e" as a parameter.  So as to enable

   RSA key blinding, such representations should be avoided.

   For Java, the RSAPrivateCrtKeySpec API can be used instead.

   Section 8.2.2(i) of The Handbook of Applied Cryptography

   [citation] discusses how to compute the remaining private key

   parameters, if needed, using only "n", "e", and "e".

9.  In the JWA spec, add a security considerations subsection "RSA Private Key Representations and Blinding" which references this JWK subsection (rather duplicating the text in JWA).

Does the working group agree with these changes?  Are there other changes that working group members believe are also needed?  (If so, please propose the desired specific wording.)

Kathleen, do these changes accomplish your goal?  If not, can you please propose specific additional text changes that you'd also like to see?

                                                                -- Mike