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

Scott Kelly <scott@hyperthought.com> Sat, 30 August 2014 13:13 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9421A0262 for <secdir@ietfa.amsl.com>; Sat, 30 Aug 2014 06:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODk5VGpgOT7e for <secdir@ietfa.amsl.com>; Sat, 30 Aug 2014 06:13:13 -0700 (PDT)
Received: from smtp66.ord1c.emailsrvr.com (smtp66.ord1c.emailsrvr.com [108.166.43.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375931A8A13 for <secdir@ietf.org>; Sat, 30 Aug 2014 06:13:11 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9AD3E18032D; Sat, 30 Aug 2014 09:13:10 -0400 (EDT)
X-Virus-Scanned: OK
Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id E85A918027D; Sat, 30 Aug 2014 09:13:09 -0400 (EDT)
X-Sender-Id: scott@hyperthought.com
Received: from [192.168.128.24] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Sat, 30 Aug 2014 13:13:10 GMT
From: Scott Kelly <scott@hyperthought.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com>
Date: Sat, 30 Aug 2014 06:13:08 -0700
To: secdir@ietf.org, draft-ietf-jose-json-web-encryption.all@tools.ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gSgizmypUAC1DmlqcAZqnofHKjQ
Subject: [secdir] secdir review of draft-ietf-jose-json-web-encryption-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 13:13:14 -0000

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.