Re: [jose] #28: AES-GCM should not be allowed for content encryption in combination with Direct Encryption key management mode

"jose issue tracker" <trac+jose@trac.tools.ietf.org> Thu, 01 August 2013 01:22 UTC

Return-Path: <trac+jose@trac.tools.ietf.org>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627D921F93D4 for <jose@ietfa.amsl.com>; Wed, 31 Jul 2013 18:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbTPmskn8pab for <jose@ietfa.amsl.com>; Wed, 31 Jul 2013 18:22:55 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8C321F9A65 for <jose@ietf.org>; Wed, 31 Jul 2013 18:22:51 -0700 (PDT)
Received: from localhost ([127.0.0.1]:52518 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+jose@trac.tools.ietf.org>) id 1V4hbK-0003uG-KY; Thu, 01 Aug 2013 03:22:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: jose issue tracker <trac+jose@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, ietf@augustcellars.com, mpeck@mitre.org
X-Trac-Project: jose
Date: Thu, 01 Aug 2013 01:22:46 -0000
X-URL: http://tools.ietf.org/jose/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/jose/trac/ticket/28#comment:4
Message-ID: <069.36ce8339e9839b43bc82d7abf6ff92f1@trac.tools.ietf.org>
References: <054.7c33f2d20d536f291cb1402eed2d1710@trac.tools.ietf.org>
X-Trac-Ticket-ID: 28
In-Reply-To: <054.7c33f2d20d536f291cb1402eed2d1710@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, ietf@augustcellars.com, mpeck@mitre.org, jose@ietf.org
X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mbj@microsoft.com
Resent-Message-Id: <20130801012251.3C8C321F9A65@ietfa.amsl.com>
Resent-Date: Wed, 31 Jul 2013 18:22:51 -0700
Resent-From: trac+jose@trac.tools.ietf.org
Cc: jose@ietf.org
Subject: Re: [jose] #28: AES-GCM should not be allowed for content encryption in combination with Direct Encryption key management mode
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2013 01:22:56 -0000

#28: AES-GCM should not be allowed for content encryption in combination with
Direct Encryption key management mode


Comment (by mpeck@mitre.org):

 Thank you for adding the security considerations text.  However, I don't
 believe it is sufficient, as I don't think it is practical to expect
 implementations to be able to keep track of how many times the pre-shared
 key has been used.  When possible, cryptographic standards should be
 designed in a way that resists easy misuse / misimplementation.  For GCM
 key wrap, the potential consequences seem especially bad since it is keys
 that are being encrypted.

 BCP 107 / RFC 4107 Section 2.1 states that "Automated key management MUST
 be used" when "Any stream cipher...is used."  Section 2.2 states that "The
 burden of demonstrating that manual key management is appropriate falls to
 the proponents -- and it is a fairly high hurdle."

 Existing RFCs that specify use of GCM in Internet protocols require
 automated key management.
 GCM in CMS (RFC 5084) uses a fresh content encryption key for each CMS
 message.
 GCM in IPsec ESP (RFC 4106) states (Section 2) that "implementations MUST
 use an automated key management system, such as the Internet Key Exchange"
 rather than allowing use of statically configured keys.

 I suggest the following changes:

 Prohibit use of GCM content encryption algorithms in combination with the
 Direct Encryption key management mode (when the value of "alg" is "dir").
 There are other content encryption algorithms that are less risky in this
 case.

 As there appears to be a use case for AES-GCM Key Wrapping, we should
 explore options to ensure that a new key is used for each AES-GCM Key Wrap
 operation.  For example, run the pre-shared key through the Counter Mode
 KDF (NIST SP 800-108 Section 5.1) to get the AES-GCM Key Wrap Key -- the
 KDF could mix in information like algorithm identifiers (might help
 prevent the issue James Manger pointed out of mixing up AES-GCM Content
 Encryption with AES-GCM Key Wrap, though I still think direct encryption
 should be prohibited with AES-GCM Content Encryption) and a sender-
 provided random value (to make sure a new key is used each time).  Section
 2 of SP 800-108 says its KDFs can be used for this use case (to derive
 keys from a pre-shared key).

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  mpeck@mitre.org        |  algorithms@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  algorithms             |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/jose/trac/ticket/28#comment:4>
jose <http://tools.ietf.org/jose/>