[jose] AEAD-only

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 17 October 2012 05:32 UTC

From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Date: Wed, 17 Oct 2012 16:32:38 +1100
Thread-Topic: [jose] AEAD-only
Thread-Index: Ac2ra69SDtelvfepRBCO1gAjjbxxsQAs/NCA
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FDDCC27D@WSMSG3153V.srv.dir.telstra.com>
References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [jose] AEAD-only
Precedence: list

It is great to see "A128CBC+HS256" as a name for an AEAD algorithm (instead of 3 names for enc/int/kdf components).

The rest of the JWE spec needs further edits to properly reflect the AEAD-only model — as does the JWA spec.

1. Drop section 3.2. "Example JWE with a Separate Integrity Check"; rename section 3.1 to be "Example". The difference between an "integrated" AEAD algorithm (eg A256GCM) and a "constructed" AEAD algorithm (eg A128CBC+HS256) shouldn't be visible at this level (ie in this spec).

2. Section 5 "Message Encryption" step 1: the size of the CMK is determined by the AEAD algorithm (enc parameter value), not the size required for the block encryption algorithm.

3. Section 5 "Message Encryption". There is no mention of what the Additional Data is for the AEAD algorithm. Add a step 11b that defines what the Additional Data is. Adjust step 12 to say the (compressed) plaintext and Additional Data are passed to the AEAD algorithm.

4. Section 6 "Message Decryption". As above, a step needs to specifying what the Additional Data is.

5. Section 1 "Introduction". It would be worth mentioning that an AEAD algorithm is used to provide confidentiality and integrity, along with the model of an AEAD algorithm (fixed length symmetric key; plaintext and Additional Data inputs; iv?; ciphertext and integrity tag outputs).

6. Section 4.1.2. ""enc" (Encryption Method) Header Parameter". Say it is an AEAD algorithm. Explicitly state that the "enc" value must imply a specific key length. A specific key length is required for key agreement or for generating a random CMK.

In JWA:

7. Section 4.8.3 "Integrity Calculation for "A128CBC+HS256" and "A256CBC+HS512"" should refer to the Authenticated Data passed to the algorithm. It should not redefine how the Authenticated Data is built from dots and base64url-encodings.

8. Section 4.9 "Plaintext Encryption with AES GCM" similarly should not redefine how the Authenticated Data is built.

Choosing to only support AEAD algorithms was a good choice. It should make it easier to understand the security properties. However, at the moment different AEAD algorithm use different inputs for the Authenticated Data portion, which really undermines any understanding of the security.

--
James Manger

[jose] JOSE and JWT specs incorporating working g… Mike Jones
Re: [jose] JOSE and JWT specs incorporating worki… Vladimir Dzhuvinov / NimbusDS
Re: [jose] JOSE and JWT specs incorporating worki… Mike Jones
[jose] xpo Manger, James H
Re: [jose] xpo Richard Barnes
[jose] AEAD-only Manger, James H
Re: [jose] xpo Sean Turner
Re: [jose] xpo Nat Sakimura
Re: [jose] xpo Matt Miller (mamille2)