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

Michael Jones <michael_b_jones@hotmail.com> Fri, 09 November 2012 18:06 UTC

Return-Path: <michael_b_jones@hotmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 043F921F8506 for <jose@ietfa.amsl.com>; Fri, 9 Nov 2012 10:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id x5dVFVhDz92i for <jose@ietfa.amsl.com>; Fri, 9 Nov 2012 10:06:22 -0800 (PST)
Received: from bay0-omc1-s23.bay0.hotmail.com (bay0-omc1-s23.bay0.hotmail.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E321F84B1 for <jose@ietf.org>; Fri, 9 Nov 2012 10:06:22 -0800 (PST)
Received: from BAY171-W32 ([]) by bay0-omc1-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 10:06:22 -0800
Message-ID: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>
Content-Type: multipart/alternative; boundary="_cbe74add-56f7-4f15-97c9-4e15d77cddaf_"
X-Originating-IP: []
From: Michael Jones <michael_b_jones@hotmail.com>
To: jose@ietf.org
Date: Fri, 09 Nov 2012 10:06:22 -0800
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Nov 2012 18:06:22.0387 (UTC) FILETIME=[ED023030:01CDBEA4]
Subject: [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: Fri, 09 Nov 2012 18:06:23 -0000

Some working group members, including Axel, James, Matt, and
Richard have expressed dissatisfaction with the use of the Concat KDF to
generate the CEK and CIK when AES CBC is the block encryption algorithm.  Reasons stated are implementation complexity
and possible issues with following the letter of the law of the NIST spec.  Axel and Richard had both written suggesting an
alternative – let the CMK be simply the concatenation of the CEK and the CIK
values.  This is the same approach used
in draft-mcgrew-aead-aes-cbc-hmac-sha2.


I and others had argued against this for size
reasons.  For A128CBC+HS256 this would
increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this
would increase the CMK size from 512 bits to 768 bits.  In the first case, after base64url encoding, one
would expect the extra 128 bits to require about an extra 21 bytes in the JWE.  The interesting fact though, is that when an
RSA algorithm is used to encrypt the CMK, the output size is same as the RSA key
size – in our case, a minimum of 2048 bits. 
Thus, for any combination of “alg”:”RSA1_5” or “RSA-OAEP” and “enc”:”A128CBC+HS256”
or “A256CBC+HS512” there is no actual
size difference in the JWE.  (However
when “alg”:”A128KW” or “A256KW” are used, there would be a size increase of
about 21 or 43 bytes, respectively.)


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?


                                                            Thanks all,



P.S.  A KDF will
still be required for ECDH-ES key agreement. 
I’ll address James’ concerns about our use of Concat in a separate note.