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/>
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker
- [jose] #28: AES-GCM should not be allowed for con… jose issue tracker
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker
- Re: [jose] #28: AES-GCM should not be allowed for… jose issue tracker