Last Call Review of draft-ietf-jose-json-web-encryption-31
review-ietf-jose-json-web-encryption-31-secdir-lc-kelly-2014-09-04-00

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.

From the abstract, JSON Web Encryption (JWE) represents encrypted content using
JavaScript Object Notation (JSON) based data structures. A little like CMS for
web transactions.

The security considerations section begins

   "All of the security issues that are pertinent to any cryptographic
   application must be addressed by JWS/JWE/JWK agents.  Among these
   issues are protecting the user's asymmetric private and symmetric
   secret keys, preventing various attacks, and helping avoid mistakes
   such as inadvertently encrypting a message to the wrong recipient.
   The entire list of security considerations is beyond the scope of
   this document, but some significant considerations are listed here."

  "All the security considerations in the JWS specification also apply
   to this specification.  Likewise, all the security considerations in
   XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other
   than those that are XML specific."

If you are going to point to the JWS specification, you should use a normative
reference. It's fine to point at other references to avoid re-stating the
obvious, but all security considerations *are* within scope, and require
coverage, either directly or by reference. I haven't reviewed the referenced
W3C spec, so I'm not sure that everything has been covered. The JWS security
considerations section only talks about crypto algs and server identity
verification. So, the ADs will want to pay attention here.

In section 5.1 (Message Encryption), step 16 says "Encrypt M..." without ever
defining M. One might guess it stands for Message, but this should be stated.

Section 8 (TLS Requirements) points at JWS, but neither document references the
channel binding problem. If you are depending on TLS to provide essential and
necessary security features (which, presumably, you are since TLS is a MUST),
then you should give clear guidance as to how to effectively use it. JWS
requires combined confidentiality and integrity protection, and also requires
server identity verification per RFC6125, but does not mention channel binding.

Section 11.1 (Using Matching Algorithm Strengths) says

  "Algorithms of matching strengths should be used together whenever
   possible.  For instance, when AES Key Wrap is used with a given key
   size, using the same key size is recommended when AES GCM is also
   used."

This doesn't quite scan for me, but editorial nits aside, it might be good to
say greater or equal key sizes should be used for wrapping. And you might want
to point to RFC3766 for BCPs when using public keys.

Section 11.2 introduces the term "key tainting". "Strict key management/usage
policy" might be better understood. Also, it might be valuable to use SHOULD
here.

I was surprised not to see any mention of the lack of replay protection. TLS
channel binding could presumably be leveraged for this purpose, but in any
event, the fact that JWEs can be replayed should be mentioned.

I would suggest that the authors read the security considerations in rfc5652;
most of the same concerns apply here, and you could almost cut/paste from there
to here.

For the ADs: I'm not sure if one of the companion documents provides a
comprehensive threat model, but you will want to pay attention here. This doc
does not.