[secdir] secdir review of draft-ietf-jose-json-web-encryption-31

[Scott Kelly <[e-mail]>]

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.