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

Axel Nennker <ignisvulpis@gmail.com> Fri, 09 November 2012 18:48 UTC

Return-Path: <ignisvulpis@gmail.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 9C40B21F84EB for <jose@ietfa.amsl.com>; Fri, 9 Nov 2012 10:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level:
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 rCV4cg-L+Oqj for <jose@ietfa.amsl.com>; Fri, 9 Nov 2012 10:48:33 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEC21F84E6 for <jose@ietf.org>; Fri, 9 Nov 2012 10:48:33 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1920630wgb.13 for <jose@ietf.org>; Fri, 09 Nov 2012 10:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTpx/AuWX0N/2Zy4tvrQvTLC76IzOtW4N5GU1xY1qxk=; b=ikw5VX8zIrshjMA8Yd/3pXOR2ZRXM1jiM8fRpxQIwgUM4YLkrCCa03tWGnhvgRTgUz tEU+dXMcPsH6/IvhXgldYYowjhFauNcXY3U+kLIWGh1QrdQqWJWUK3eGfAXHJtBoPVSH AaZCKMoQVgLQoE16MJ95BEFR3JUK3Nv7vcsLbje90+P8zPWnjesZMw4HyLMLeECGOufI mhH71rErg3Ef7a6uClV0tK85BPa3VYNMxwq7VX8yq81T1BrpW8IaHFoE23MDX3kMKTGK VXSnIdLpYPLxcwNlr76r34eNjeiAkIxzqi5mHc1oCypXDzXEdTmKwxmDmnJ6SO7XHBOl OhBA==
MIME-Version: 1.0
Received: by 10.180.87.74 with SMTP id v10mr4096993wiz.21.1352486912663; Fri, 09 Nov 2012 10:48:32 -0800 (PST)
Received: by 10.216.54.130 with HTTP; Fri, 9 Nov 2012 10:48:32 -0800 (PST)
In-Reply-To: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>
References: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>
Date: Fri, 09 Nov 2012 19:48:32 +0100
Message-ID: <CAHcDwFyY+onxMKuz+e=K9kg5WTjo4QkL8n1sekFfa5aHwJioVA@mail.gmail.com>
From: Axel Nennker <ignisvulpis@gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Content-Type: multipart/alternative; boundary="f46d0444032efe224604ce1465de"
Cc: "jose@ietf.org" <jose@ietf.org>
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: Fri, 09 Nov 2012 18:48:34 -0000

My suggestion did not change the CMK size. I think it can stay as is.
I think that the concat-kdf is hard to  implement in Firefox/NSS in
Javascript if more than one iteration is needed. For the examples in the
spec there is no iteration and so there  is no problem.
There is a problem when NIST compliance is really required because CEK and
CIK should be computed in one go.
I could live with a NIST-like concat-KDF. I think openid connect even does
not need the  optional sender/receiver-ids.
Most important is the randomness of the CMK.

I don't understand the choices you provided. I think the CMK can stay a
defined.

// cmk size matters. more bytes give better cik and cek.
// cmk size does not change encodedEncryptedKeySegment if alg = RSA1_5 or
RSA-OAEP
cmk = generateRandomKey(size, enc);
// cik and cek have as many bytes as required by enc
(cik,cek) = some-kdf(cmk, otherInfoInput);

Axel



2012/11/9 Michael Jones <michael_b_jones@hotmail.com>

>  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,***
> *
>
>                                                             -- Mike****
>
> ** **
>
> 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.****
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>