Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

"Manger, James H" <James.H.Manger@team.telstra.com> Tue, 13 November 2012 06:33 UTC

Return-Path: <James.H.Manger@team.telstra.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 1AE9021F88E6 for <jose@ietfa.amsl.com>; Mon, 12 Nov 2012 22:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.727
X-Spam-Level:
X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
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 QMENQ+Ta9QiJ for <jose@ietfa.amsl.com>; Mon, 12 Nov 2012 22:33:48 -0800 (PST)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id C96F621F88E4 for <jose@ietf.org>; Mon, 12 Nov 2012 22:33:47 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.80,765,1344175200"; d="scan'208,217"; a="101285960"
Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 13 Nov 2012 17:33:32 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="92856483"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 13 Nov 2012 17:33:32 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 13 Nov 2012 17:33:31 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "David McGrew (mcgrew)" <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>, "jose@ietf.org" <jose@ietf.org>
Date: Tue, 13 Nov 2012 17:33:30 +1100
Thread-Topic: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgCAAFxuQA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E115004FD4BA@WSMSG3153V.srv.dir.telstra.com>
References: <BAY171-W133C34B6212813A7B59F439B76D0@phx.gbl> <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.com>
In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
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, 13 Nov 2012 06:33:49 -0000

+10

This is much clearer, and much more suitable for separating what goes in a JOSE library vs what goes in a general-purpose crypto library. Even if a JOSE library needs to implement parts of the crypto today because native AEAD support is not yet present, this solution makes it much more likely JOSE will be compatible with native AEAD as it becomes available. I think it is unlikely that native AEAD support (once available) would support both JOSE and draft-mcgrew variants of AEAD-from-AES-CBC-HMAC. The draft-mcgrew variant has a better chance of being implemented because it doesn’t impose a 33% performance penalty for the MACing part, and the other differences are trivial.

The fact that some existing AEAD algorithms (SIV [RFC 5297]) don’t produce a separate authentication tag is a clear indication that a single ciphertext output is a better general model for AEAD in JOSE than separate ciphertext and integrity values as in JWE today.

Editorials:
“JWE Initialization Vector” should be renamed “JWE Nonce”.
The nonce paragraph needn’t hardwire 2 lengths (0 and 96 bits) – leave it to each alg to specify.
The table can include key and nonce sizes.
    "enc"                key size    nonce size  Algorithm
    -----------------------------------------------------------------------
    "A128GCM"   16 bytes    12 bytes     AEAD_AES_128_GCM
    "A256GCM"   32 bytes    12 bytes     AEAD_AES_256_GCM
     "A128CHS"     48 bytes     0 bytes      AEAD_AES_128_CBC_HMAC_SHA_256
     "A256CHS"     64 bytes     0 bytes      AEAD_AES_256_CBC_HMAC_SHA_512

--
James Manger

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; cfrg@irtf.org; jose@ietf.org
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

…
I am not dogmatically opposed to other interfaces, but the best solution here is for JOSE to actually use the 5116 interface, like this:

X.Y. Authenticated Encryption

   This section defines the specifics of encrypting the JWE Plaintext
   Using the Authenticated Encryption with Associated Data (AEAD)
   as defined in RFC 5116.   The authenticated encryption operation
   has four inputs, as follows:

     The secret key is the CMK.

     The associated data is the bytes of the ASCII representation of the concatenation of
     the Encoded JWE Header, a period ('.') character, the Encoded JWE
     Encrypted Key, a second period character ('.'), and the Encoded JWE
     Initialization Vector, per Section 5 of the JWE specification.

      The plaintext , which contains the data to be encrypted and
      authenticated.

      A nonce N, with a length of either 0 or 96 bits.   If the length
      is zero, the nonce is omitted.  Otherwise, the nonce
      is as described in Section 3 of RFC 5116.

   There is a single output, the Ciphertext.

   The "enc" header  parameter values are set as follows:

    "enc"                  Algorithm
    -----------------------------------------------------------------------
    "A128GCM"     AEAD_AES_128_GCM
    "A256GCM"     AEAD_AES_256_GCM
     "A128CHS"      AEAD_AES_128_CBC_HMAC_SHA_256
     "A256CHS"      AEAD_AES_256_CBC_HMAC_SHA_512
      "A128SIV"      AEAD_AES_SIV_CMAC_256
      "A256SIV"      AEAD_AES_SIV_CMAC_384

      See <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml><http://www.iana.org/assignments/aead-parameters/aead-parameters.xml%3e> for the
     references corresponding to these symbolic names.