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

From: [email-masked]
Date: Sat, 12 May 2012 16:45:38 -0700

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-algorithms-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/

---

From: "Juraj Somorovsky" <[email-masked]>
Date: 14 May 2012 14:15:37 +0200

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:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

-- 
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

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 May 2012 19:03:38 +0000

I'll plan on describing these countermeasures in the Security Considerations section.

Thanks,
-- Mike

________________________________
From: Juraj Somorovsky
Sent: 5/14/2012 5:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt

Hi,

Thanks
Regards
Juraj

--
M.Sc. Juraj Somorovsky

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 May 2012 13:35:54 -0400

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?

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?

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.

4) s3: Expand MAC

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

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

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

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

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

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.

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

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.

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

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.

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.

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.

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.

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.

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

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-resistent 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.

- 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.

- 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?

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.

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?

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]                                      |

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 ;)

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.

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.

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

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

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.

27) s4.3: r//>/

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.

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.

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

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

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

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

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 ...

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.

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?

37) s5.3.2: Should we specifying that e=65537 must 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.

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

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.

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.

spt