Re: [jose] Use of AES-HMAC algorithm - Consensus Request

John Bradley <ve7jtb@ve7jtb.com> Tue, 09 April 2013 11:06 UTC

Return-Path: <ve7jtb@ve7jtb.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 7020E21F9156 for <jose@ietfa.amsl.com>; Tue, 9 Apr 2013 04:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level:
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 PPcLQsokIiV4 for <jose@ietfa.amsl.com>; Tue, 9 Apr 2013 04:06:55 -0700 (PDT)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 586F721F913C for <jose@ietf.org>; Tue, 9 Apr 2013 04:06:55 -0700 (PDT)
Received: by mail-vb0-f48.google.com with SMTP id p13so4567184vbe.35 for <jose@ietf.org>; Tue, 09 Apr 2013 04:06:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=LNbFUKTBJfcoV4mLq0R6M83pgFNZK4jdS4Pq+mkU2Ps=; b=dFX4Bj4FW3sdYOSh/xbCBIxcTJNWPzmWEGByifSE5Q7aFhsQ0AJHelwaTZaKZVzIpC cTGa5Y3CrDXUva9F1clLv0bncyl3BNkFqbPZjK1gmzahOCdVzxk+El9uoTLXfr2ujhKV IX6HFBiJ0BIh8SW6hpGaIvuRTAXKfXYbErrw7uYA9V6vwMeAiIAuK8CtiRtNR2x2dXxv VcJHMGdbBNPkTXIZm+vwaYu1aa1kB6eIBgTU3XSt38Y55YQeBXZY2XjTHYyutHVGc6ak xU4lWFByqnE6x+aVVrRH+LMLQ5iYkJcHOP97zNBQ3G2dCqgt9YsNoDrJglg+jZiFyo08 e6CA==
X-Received: by 10.52.183.36 with SMTP id ej4mr5952843vdc.95.1365505614593; Tue, 09 Apr 2013 04:06:54 -0700 (PDT)
Received: from [192.168.6.138] (ip-64-134-102-253.public.wayport.net. [64.134.102.253]) by mx.google.com with ESMTPS id s9sm28619871veb.5.2013.04.09.04.06.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 04:06:53 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_6D4F3AB3-78A8-495A-B593-77BBC640EF8B"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CABzCy2B3ctmYQjvfw1bVxSoO=YwWvp4F53OHKuoUVzfJmQqDNA@mail.gmail.com>
Date: Tue, 09 Apr 2013 07:06:41 -0400
Message-Id: <F33E8E94-B3C8-43C5-AF2A-E022629A3D66@ve7jtb.com>
References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG> <CDF230A7-15ED-4722-BDFC-364D8A1975B8@gmail.com> <BF7E36B9C495A6468E8EC573603ED941151B6F48@xmb-aln-x11.cisco.com> <CABzCy2B3ctmYQjvfw1bVxSoO=YwWvp4F53OHKuoUVzfJmQqDNA@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
X-Mailer: Apple Mail (2.1503)
X-Gm-Message-State: ALoCoQn6ozH3pokzOh2HVi/kAwUDvI2VHhWBQHOwx7/70QbRbtj6Est02qv66syXDFNf8wtkQGb7
Cc: Jim Schaad <ietf@augustcellars.com>, Dick Hardt <dick.hardt@gmail.com>, "Peck, Michael A" <mpeck@mitre.org>, "jose@ietf.org" <jose@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>
Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request
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: Tue, 09 Apr 2013 11:06:56 -0000

Concatenating the keys together as in McGrew, not the Concat KDF as in the current spec?

I think I know what you mean but just double checking.

John B.
On 2013-04-08, at 7:29 PM, Nat Sakimura <sakimura@gmail.com> wrote:

> Concat is what McGrew algorithm does it, is it not? I support the move.
> 
> 2013/4/9 Matt Miller (mamille2) <mamille2@cisco.com>:
>> +1 on a longer key.
>> 
>> 
>> - m&m
>> 
>> Matt Miller < mamille2@cisco.com >
>> Cisco Systems, Inc.
>> 
>> On Apr 7, 2013, at 10:47 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>> 
>>> FWIW: I'd strongly prefer a longer key than a different KDF scheme.
>>> 
>>> On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" <mpeck@mitre.org> wrote:
>>> 
>>>> I prefer using a KDF, as I think the approach of using a long key over-complicates key management by requiring generation and transport of a longer key than necessary, and it may also provide a false sense of the overall security level.
>>>> 
>>>> As previously discussed, the Concat KDF is not appropriate, but there are other NIST KDFs that seem acceptable for this key expansion purpose.
>>>> For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1, with the PRF algorithm set to the same HMAC algorithm used in the corresponding AEAD algorithm.  (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512).
>>>> 
>>>> For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128-bit "master" key:
>>>> Expanded key = HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00)
>>>> AES key = first 128 bits of expanded key
>>>> HMAC key = second 128 bits of expanded key
>>>> 
>>>> If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it would be worth discussing with the draft authors whether they are interested in performing the KDF in the AEAD algorithm itself (for example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be responsible for deriving the 128-bit AES key and 128-bit HMAC key).
>>>> 
>>>> Mike
>>>> 
>>>>> -----Original Message-----
>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>>>> Jim Schaad
>>>>> Sent: Thursday, April 04, 2013 7:51 PM
>>>>> To: jose@ietf.org
>>>>> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request
>>>>> 
>>>>> <chair>
>>>>> 
>>>>> At the request of the editors, this is a formal consensus call on the first
>>>>> item in the list below.  If there are objects to use a single long key
>>>>> rather than a KDF function for the AES-CBC/HMAC algorithm please speak up
>>>>> now.  To date nobody has said that I was wrong to assume the consensus on
>>>>> that item.
>>>>> 
>>>>> Call ends in one week.
>>>>> 
>>>>> Jim
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>>>> Jim
>>>>>> Schaad
>>>>>> Sent: Wednesday, March 27, 2013 3:21 PM
>>>>>> To: jose@ietf.org
>>>>>> Subject: [jose] Use of AES-HMAC algorithm
>>>>>> 
>>>>>> <chair>
>>>>>> After spending time looking at and thinking about how to resolve this
>>>>> issue
>>>>>> since I was unable to do so at the last F2F meeting.  I have come up with
>>>>> the
>>>>>> following set of issues that might need to be addressed as part of
>>>>> resolving
>>>>>> this issue.
>>>>>> 
>>>>>> 1.  Do we change from using KDC to having a double size key for the
>>>>>> algorithm?  I think that there is probably a consensus that this should be
>>>>> done.
>>>>>> 
>>>>>> 2. Should IVs be prepended to the encrypted body as part of the encoding
>>>>>> steps?  If so then this change should be universal.
>>>>>> 
>>>>>> Doing so would eliminate one field from all of the encoding formats which
>>>>>> should be considered a plus.
>>>>>> Doing so would force code writers to understand how large the IV is for
>>>>> all
>>>>>> algorithms as the IV would no longer be a separate item.
>>>>>> 
>>>>>> 3. Should Authentication Tags be appended to the encrypted body as part of
>>>>>> the encoding steps?
>>>>>> 
>>>>>> Doing so would eliminate one field from all of the encoding formats which
>>>>>> should be considered a plus.
>>>>>> Doing so would force code writers to understand how large the IV is for
>>>>> all
>>>>>> algorithms as the IV would no longer be a separate item.
>>>>>> Doing so would force a re-organization for the multiple recipient case as
>>>>>> either all recipient specific data would need to be excluded from the
>>>>>> authentication step or all of the recipient data would need to be included
>>>>> for
>>>>>> by all recipients.
>>>>>> Changing how the recipient info is process is going to give a performance
>>>>>> benefit for sending encrypted items for multiple recipients.
>>>>>> The current strategy of a single IV and key pair with AES-GCM and
>>>>> different
>>>>>> authentication data needs to have CFRG look at it.  I am worried that it
>>>>> might
>>>>>> be a serious security flaw.
>>>>>> 
>>>>>> 4. Should we reference the McGrew draft and provide text on how things
>>>>> are
>>>>>> changed or should we "copy" the draft into our text?
>>>>>> 
>>>>>> 5.  If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping,
>>>>>> does this change how we think about any of the above questions?
>>>>>> 
>>>>>> Allowing for AES-GCM for key wrapping has a benefit for hardware
>>>>> situations
>>>>>> as only the encrypt and not the decrypt functions need to be placed in
>>>>>> hardware.  However allowing for this key wrapping give a problem as there
>>>>> is
>>>>>> no way to encode the three fields into the encrypted value unless with use
>>>>>> either a JSON structure in this location or we do use the single appended
>>>>>> binary output stream.  The first approach leads to an expansion of the
>>>>> field by
>>>>>> double base64 encoding which is highly undesirable.
>>>>>> 
>>>>>> Jim
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> jose@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>> 
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose