Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 17:52:03 +0000

Thanks for taking the time to provide the detailed feedback.  Responses inline...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt

Here are some comments (I'll try not to duplicate Jim's):

1) s1/s6: (wherever the registry gets established): s1 contains the

following:

  in the face of changes in

  the set of required, recommended, optional, and deprecated algorithms

  over time.

Did you intend for the registry to include a column indicating the whether the algorithm is required, recommended, optional or deprecated?

Good idea - Done

2) General: In other specs, we would give a hint to implementers with + and - to indicate which direction the algs were headed: + moving up the support ladder and - moving down the support ladder.  E.g., SHOULD+ would indicate that in the next version that alg was probably going to be a MUST.  Is this worth adopting here?

Good idea - Done

3) s2 & Requirements Language: The RFC editor is going to move the Requirements Language section later on so you might as well save them the trouble and just make it part of s2.

Done

4) s3: Expand MAC

Done

5) Alg Names: It's probably worth pointing out that the alg parameter values isn't limited to 5 characters.

Done

6) s3.1: This is related to #1: Should we just add a column to indicate the support level?

Done

7) s3.1: Add a column for key size too?

Not done, since a value for this column is not needed in all cases

8) s3.1: HMAC SHA-256 is the default?  UGH!

Neither RSA SHA-256 nor ECDSA P-256 SHA-256 are required because in some cases, deployments may only want to use RSA because it's commonly deployed, whereas in other cases, deployments may only want to use Elliptic Curve for size and computational speed reasons.  Thus, since there's no clear choice for asymmetric algorithms, neither is required (although both are RECOMMENDED).  Whereas, there's a clear choice for symmetric algorithms.

9) s3.2: Consider a reference to RFC 6234 because it contains sample code for the listed HMACs.

If this spec were about implementing the HMAC algorithms, I would definitely add this, but given it's about using the algorithms, the reference seems unnecessary (just as I believe Jim's suggested reference to RFC 4231 was).  But like I told Jim about 4231, feel free to push back on this...

10) s3.2: Add reference to 4648 when you first mention base64url.  Also need to specify the alphabet you're going to use - I'd point to the section and not assume "url" is enough.

Base64url Encoding is defined in the terminology section, and does include a 4648 reference.

11) s3.2: Add a normative reference to RFC 3629 for UTF-8.

The first use of UTF-8 does include a 3629 reference - again, in the terminology section.

12) s3.2: Two steps for the HMAC: I think it would be clearer to talk about this in terms of 2104.  I think that means:

The HMAC SHA-256 MAC is generated as follows:

- text, see [RFC2104], is the bytes of the UTF-8 representation of the JWS Secured Input

- use HMAC-256 as the hash algorithm H

The output is then base64url encoded and is used as the Encoded JWS Signature for that JWS.

Ditto for the validation bit.

Completed rewrote this part to simplify it, based upon your input above

13) FIPS references: Consider using DSS and SHS instead of FIPS.186-3 and FIPS.180-3.

Done

14) Not sure we need the following:

  Note that while Section 8 of RFC 3447 [RFC3447] explicitly calls for

  people not to adopt RSASSA-PKCS1 for new applications and instead

  requests that people transition to RSASSA-PSS, for interoperability

  reasons, this specification does use RSASSA-PKCS1 because it commonly

  implemented.

RFC 3447 is informational and I believe it's essentially an RSA Labs document.  If you're going to keep this then maybe we need to be clearer that RFC 3447 says this and that it's an RSA spec.

Per Jim's comment, this text has been removed and a modified form of it now appears in the Security Considerations section.

15) s3.4: The 160-bit key is which key public or private?  And, why isn't the key size linked to the curve?  256 for P-256, 384 for P-384, and 521 for P-521.

Removed per Jim's comment, since the key size is implied by the algorithm.

16) s3.4: I'm not sure if this is worth pointing out or not, but other EC key format specs include one extra byte at the beginning to indicate the key type: uncompressed, compressed, hybrid, etc.

This isn't a key representation - it's signature output.

17) s3.4: In this step:

  2.  The output of the base64url decoding MUST be a 64 byte array.

Add that: If decoding does not result in a 64 byte array, the JWS MUST be rejected.

Done

18) s3.4: I'm no cryptographer, but I think the following is wrong if you mean the validator needs to be given k in addition to the public key and r,s:

  The consequence of this is that one must validate an ECDSA digital

  signature by submitting the previously specified inputs to an ECDSA

  validator.

SHS points to ASNI for signature verification and I don't have that handy so I went to the Suite B implementers guide

(http://www.nsa.gov/ia/_files/ecdsa.pdf) to look for the signature ECDSA verification steps.  I didn't see k as being needed when you verify.

Reworded to hopefully eliminate the potential confusion

19) s3.5: Is this section for authenticated encryption algs or because the lower layers are taking care of authentication/integrity?

Reworded, per Jim's comment.  (It's because integrity is being provided by other means or isn't necessary in the use cases for this feature.)

20) s3.1/s3.6, s4.1-3/s4.11, s5.1/s.5.4, and s6.*: A couple of things about these paragraphs made me scratch my head:

20.1) Registry: Normally, we set up a registry to restrict the values used in a protocol.  This sets the MTI, establishes a registry with RFC required, and then lets everybody off the hook with an well-known/collision-resistant URI.  It seems like nobody would ever go the RFC route - ever.  A couple of thoughts:

- Do we need the following: "URI that contains a collision resistant namespace"?  Implementations are free to support whatever they want and I'm sure somebody will ask you to define what "a collision resistant namespace" is.

"Collision Resistant Namespace" was already defined in JWT.  I've added the definition to JWS, JWE, JWK, and JWA as well.

The registries are only needed in this case to prevent collisions when names not containing a collision-resistant namespace, such as "example" are defined.  It's perfectly fine to use names like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier or urn:oasis:names:tc:SAML:2.0:assertion or 73a7c4e8-8296-43e3-ba77-46730a3e9e57 (a GUID) without using the registries, as no name conflicts will arise.

- Maybe the registry should just be Specification Required + Expert review?  That way it's more of level playing field.  I can't see anybody ever doing an RFC if all they need is a collision resistant namespace.

Done

- On the other hand are you trying to say that the MTI alg must be set in a standards track RFC but other values maybe specified in elsewhere?

No.  This was just language that was cut-and-pasted in while writing the spec.  It's been changed now, per your comment above.  Please review.

20.2) Algorithm naming: Being new to the block, I'm trying to understand why we can't reuse an already well know identifier for the algs.  (just picking on the first set of algs but this applies to them all)

HMAC-SHA256 is pretty well understood so I'm wondering whether it is really worth saving five bytes over HS256?  Ditto for RSAwithSHA* and ECDSAwithSHA*;  I guess you're saving more with these, but I question whether it's really worth adding yet another way to name an alg.

This was a result of a consensus decision among the collaborators who jointly developed the JWT spec, which was also publicly reviewed and confirmed shortly thereafter at the Internet Identity Workshop in November, 2010.  Given that some browsers have (short) URI length restrictions and we wanted to be able to use JWTs in URI query parameters, keeping the representations compact was a core goal of the specification.

20.3) Duplication identifiers (might partially go away based on 20.2):

(just picking on the first set of algs but this applies to them all) What are we going to do about duplicate identifiers?  Right now HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 are defined as well as ECDSA/RSA with SHA-256, etc. in XMLDsig.  There's also some defined by RSA in RFC 4231.  Don't we need to say something about preferring one over the other?

The registry and the use of collision resistant namespaces is intended to prevent collisions.

21) s4.1: Technically, for encryption RSA is RSAES-PKCS1-v1_5 or RSAES-OAEP so:

  | RSA1_5    | RSAES-PKCS1-1.5 [RFC3447]                             |

  | RSA-OAEP  | RSAES-Optimal Asymmetric Encryption Padding (OAEP)    |

  |           | (OAEP) [RFC3447]                                      |

Done

Actually you can replace: ", as defined in [XXXX]" in the tables in s4.1 and s4.2 with "[XXXX]" - just to make it less wordy.  And you only need to expand AES, CBC, and GCM once ;)

Done and done

22) s4.1: Need to add ECDH-ES with different curves.  If you're going to allow ECDSA P-521, then matching it with ECDH-ES P-521 makes sense.

Are there specific additional curve/hash function combinations that you'd like to make the case to the working group to add?  The current set was motivated by the choices in NIST Suite B.

23) s4.1/s4.6: Err...I don't think you should set OtherInfo to zero!? If we're using s5.8.1 then at a minimum it's AlgorithmID || PartyUInfo || PartyVInfo.

It's not clear to me what additional value these parameters add in our usage of the algorithm.  If we believe that the randomly generated ephemeral key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant AlgorithmID to the computation I don't believe changes the security properties.  (That being said, we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people felt better about doing this.)

Also given that the text now says (per a comment of Jim's) that "A new epk (ephemeral public key) value MUST be generated for each key agreement transaction", it's not clear that adding parameters identifying the participating parties adds any security value either.  That being said, I'd be glad to learn why I'm wrong.

If there are good security reasons for requiring PartyUInfo and PartyVInfo values, do you have suggestions on how to create acceptable values without carrying more parameters in the header?  (I've already suggested that we could use the alg value "ECDH-ES" as the AlgorithmID, which wouldn't require more parameters.)

For instance, I don't want to blindly follow XML ENC's lead and punt the issue by requiring that conforming uses provide explicit PartyUInfo and PartyVInfo values.

Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/html/rfc5246#section-5 uses no party parameters.  Why do we need them then?

24) s4.2: Some folks like AES-CCM - worth adding?

This could be added if the WG wants to.  I'd want us to look at how widely deployed it is when determining whether it should be any more than OPTIONAL.

25) s4.2: r/RSA-PKCS1-1.5/RSAES-PKCS1-v1_5

Done

26) s4.2: Seems like we should pair up 128 kw/cbc and 256 kw/cbc.  When you pick a set of algs they ought to be matched.

Added this to the Security Considerations:

                Algorithms of matching strength should be used together whenever possible.

                For instance, when AES Key Wrap is used with a given key size,

                using the same key size for AES CBC or GCM is recommended.

                Likewise, when AES CBC is used with a 128 bit key, using HMAC SHA-256

                as the integrity algorithm is recommended, whereas when

                AES CBC is used with a 256 bit key, using HMAC SHA-512

                as the integrity algorithm is recommended.

27) s4.3: r//>/

Done

28) s4.3: I think this is a cut/paste error:

    r/It is RECOMMENDED that

    implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256

    algorithms./It is RECOMMENDED that

    implementations also support the HMAC SHA-256 and HMAC SHA-384

    algorithms.

Replaced by the table values

29) s4.3: (no action required) Curious that plain old SHA-* isn't used here.  I guess I'll figure out why when I get to the other specs.

It's because the integrity calculation uses a key - the Content Integrity Key (CIK)

30) s4.4: r/RSA using RSA-PKCS1-1.5 padding, as defined in RFC 3447

[RFC3447]/RSAES-PKCS1-v1_5 [RFC3447]

Done

31) s4.5: r/RSA using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC 3447 [RFC3447]/RSAES-OAEP [RFC3447]

Done

32) s4.5: Way underspecified - SHA1 is the default hash alg in 3447 - need to profile the values in 3447.

Now specifies use of default parameters, as this is the version of OAEP that is most widely deployed, per my response to Jim's comment.  Other "alg" values could be defined for OAEP with different parameters if people believe it's useful and those parameter combinations are widely enough available.

33) s4.6: EC key size again - why isn't it 256-bit? And which key are we talking about?

Removed, as per comment 15

34) s4.7: Need to specify a MTI.  If you link it to the key size of the key being wrapped then it's easy: 128 key being wrapped MUST use 128 key to wrap, 256 ...

MTI now specified in "Implementation Requirements" column.  Also, see my response to #26.

35) s5.2.1: We've got a bunch of ways to name the curve :(  I think you have to say the curves are as defined in the DSS.  Brainpool has curves that also use some similar p256, p384, etc.

Done

36) s5.3: If you're going to use RSAES-OAEP or RSASSA-PSS there's a whole bunch more parameters that can be included (see RFC 4055).  Are they not going to be used?

See my response to #32

37) s5.3.2: Should we specifying that e=65537 must be used?

I've added this to the Security Considerations:

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

                Section 7.2 of <xref target="RFC3447"/>.  In particular, keys with

                a low public key exponent value must not be used.

38) s7: Because you're starting from scratch you're going to need to greatly expand this section.  However, you can avoid a lot of this by listing all the references for the algs used in this spec and say that the security considerations from those reference apply.

Done - referencing DSS names

Need to say that the key size/hash alg combo should be matched.  Some might find SP800-57 Part 1 useful.

See my answer to #26

Need to explain that really large keys can be a DOS.  Some text you might massage:

Receiving agents that validate signatures and sending agents that

  encrypt messages need to be cautious of cryptographic processing

  usage when validating signatures and encrypting messages using keys

  larger than those mandated in this specification.  An attacker could

  send certificates with keys that would result in excessive

  cryptographic processing, for example, keys larger than those

  mandated in this specification, which could swamp the processing

  element.  Agents that use such keys without first validating the

  certificate to a trust anchor are advised to have some sort of

  cryptographic resource management system to prevent such attacks.

Thanks - incorporated

Some other motherhood and apple pie that you might also include:

  All of the security issues faced by any cryptographic application

  must be faced by a JWS/JWE agent.  Among these issues are protecting

  the user's private key, preventing various attacks, and helping the

  user avoid mistakes such as inadvertently encrypting a message for

  the wrong recipient.  The entire list of security considerations is

  beyond the scope of this document, but some significant concerns are

  listed here.

Thanks - incorporated

spt

_______________________________________________

jose mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 18:25:33 +0000

Hi Juraj,

Looking at this again, it seems to me that because JWE provides integrity protection for the algorithm, it should be impossible for you to replace "RSA-OAEP" with "RSA1_5" in the header because then the integrity check will fail.  Thus, the attack that you describe below is prevented by the integrity protection of the header.

Hence, correct JWE implementations do no provide the OAEP decryption oracle that you describe.  However if I'm missing something, please point it out to me, since if there's an issue, I'd like to understand it and how to mitigate it.

				Best wishes,
				-- Mike

P.S.  Can you provide me a good reference or two that you'd suggest that I cite for countermeasures to Bleichenbacher's attack?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juraj Somorovsky
Sent: Monday, May 14, 2012 5:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt

Hi,

I just wanted to mention that I am still against the usage of PKCS1 v1.5 in the specification (which is vulnerable to the Bleichenbacher's attack). There are two more motivations to omit it:

1) If you have a server, which has a vulnerable RSA1_5 implementation (this is e.g. the case in NimbusJWT as described in this thread:
http://www.mail-archive.com/[email-masked]/msg00157.html), you can use this server also to decrypt messages encrypted with RSA-OAEP. You just have to take the original message and replace the "alg" header parameter value "RSA-OAEP" with the value "RSA1_5". This way, you can force the server to act as an RSA1_5 oracle and decrypt also the message encrypted with RSA-OAEP (you just need more oracle queries).
(tested with NimbusJWT)

2) The next motivation is the work by Bardou, Focard, Kawamoto, Steel, and Tsay (http://hal.inria.fr/docs/00/69/19/58/PDF/RR-7944.pdf), who improved the Bleichenbacher's attack and made it even more practical.

I would thus propose to remove RSA1_5. Otherewise, also the clients'
messages using RSA-OAEP will be vulnerable to the Bleichenbacher's attack.

If you want to leave RSA1_5 in your standard, I would propose to explicitly include the information about the countermeasures to the Bleichenbacher's attack and a notice that RSA-OAEP should not be used with the same key as RSA1_5.

Thanks
Regards
Juraj

On 05/13/2012 01:45 AM, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF.
> 
> 	Title           : JSON Web Algorithms (JWA)
> 	Author(s)       : Michael B. Jones
> 	Filename        : draft-ietf-jose-json-web-algorithms-02.txt
> 	Pages           : 26
> 	Date            : 2012-05-12
> 
>    The JSON Web Algorithms (JWA) specification enumerates cryptographic
>    algorithms and identifiers to be used with the JSON Web Signature
>    (JWS) and JSON Web Encryption (JWE) specifications.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithm
> s-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms
> -02.txt
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
> 
> [email-masked]

--
M.Sc. Juraj Somorovsky

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
-----------------------------------
Universitätsstr. 150, Geb. ID 2/411
D-44780 Bochum

Telefon: +49 (0) 234 / 32-26551
Fax: +49 (0) 234 / 32-14347
http://www.nds.rub.de
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose