Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

Mike Jones <Michael.Jones@microsoft.com> Wed, 14 November 2012 00:14 UTC

Return-Path: <Michael.Jones@microsoft.com>
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 0D55F21F84B9 for <jose@ietfa.amsl.com>; Tue, 13 Nov 2012 16:14:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNDkVx13Ibnu for <jose@ietfa.amsl.com>; Tue, 13 Nov 2012 16:14:37 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id B692E21F8477 for <jose@ietf.org>; Tue, 13 Nov 2012 16:14:35 -0800 (PST)
Received: from BL2FFO11FD004.protection.gbl (10.173.161.202) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.556.9; Mon, 12 Nov 2012 01:29:19 +0000
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Mon, 12 Nov 2012 01:29:19 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.11]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Mon, 12 Nov 2012 01:28:44 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "jose@ietf.org" <jose@ietf.org>
Thread-Topic: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
Thread-Index: AQHNvqT3EpFpmMO25kO23VChuPByMJflORmAgAAdecA=
Date: Mon, 12 Nov 2012 01:28:44 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943668AF1FF@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl> <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(13464001)(33656001)(46102001)(74502001)(53806001)(49866001)(4396001)(47976001)(16406001)(23676001)(47736001)(31966008)(50466001)(44976002)(5343655001)(47776002)(54316001)(47446002)(50986001)(74662001)(51856001)(54356001)(76482001)(148743001)(55846005)(217873001); DIR:OUT; SFP:; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0663390E1B
Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 14 Nov 2012 00:14:38 -0000

Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  For instance, as was discussed after David's presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two outputs (ciphertext, "authentication tag").  Instead, it adds a step combining the ciphertext and "authentication tag" outputs.

If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS512.  It requires generating and adding specific padding bytes.  It prefixes the ciphertext with the IV.  It includes the length of the "additional authenticated data" in the MAC calculation.  It combines the two outputs into one.  For decryption, likewise, the two outputs must be split apart, the IV must be split apart, etc.

All of these are steps that implementations could get wrong, resulting in interoperability problems.  By keeping all the parameters separate, our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps.

I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2.  While they both explicitly represent the CMK and CEK, and use the same underlying crypto operations, the details differ in ways that are likely to matter to implementers.  If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs separate, I agree that it would be a reasonable candidate for JOSE to consider.  But unlike AES GCM, that's not what it does.

				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Sunday, November 11, 2012 2:24 PM
To: Michael Jones; jose@ietf.org
Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

> So I’d like to explicitly ask the working group.  Do you want us to:
>
> (1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC, resulting in a longer CMK?
> (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK?


1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2

--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose