Subject: [jose] Symmetric encryption and key agreement with and without a separate CMK

From: Mike Jones <[email-masked]>
Date: Thu, 19 Jul 2012 01:04:03 +0000

Hi all,

I've been thinking about two of our open issues, which are closely related, and am writing to make a proposal to resolve both of them.  The issues are:

(1) Currently we specify methods for using symmetric keys to key wrap a separate Content Master Key (CMK), but no means of using the symmetric key as the CMK directly.  Some applications need this functionality, both for size and for efficiency reasons.

(2) Currently we specify methods for performing key agreement and directly using the resulting key as the CMK to perform block encryption, but no means of using the agreed-upon key to wrap a separate CMK.  When doing key agreement for multiple recipients, a separate CMK is needed.

Thus, I propose that we define methods for filling in both of the holes above, as follows:

(a) Define "alg":"dir" (direct) to mean that the symmetric key is directly used as the CMK for the block encryption and integrity calculations, rather than as a key to wrap the CMK value.

(b) Define "alg":"ECDH-ES+A128KW" and "alg":"ECDH-ES+A256KW" to mean that the result of the key agreement is respectively used as the 128 bit or 256 bit AES Key Wrap key to wrap the CMK.

Doing this will enable all four flavors, whereas we're currently missing 2 and 3 below:
1.  The symmetric key used to wrap a separate CMK
2.  The symmetric key used as the CMK
3.  The key agreement result used to wrap a separate CMK
4.  The key agreement result used as the CMK

I recognize that flavors 2 and 4 are not usable with multiple recipients when methods such as JWE JSON Serialization are used (which counts on a common CMK value to enable a common ciphertext value).  A note to that effect would be added to the JWA definitions of "alg":"ECDH-ES" and "alg":"dir" and it would be pointed out in the JWE-JS spec that "alg" values that utilize a separate CMK MUST be used when the plaintext is encrypted to multiple recipients.

Comments?

                                                                -- Mike

---

From: John Bradley <[email-masked]>
Date: Wed, 18 Jul 2012 23:23:39 -0600

I agree that is a reasonable approach.

In the XMPP example from earlier it was method 2 that they were using for multiple recipients, and that worked because the receiver requested the key from the sender after receiving the message.

So 2 may be useful in some multi recipient scenarios though probably not all.

John B.

On 2012-07-18, at 7:04 PM, Mike Jones wrote:

> Hi all,
>  
> I’ve been thinking about two of our open issues, which are closely related, and am writing to make a proposal to resolve both of them.  The issues are:
>  
> (a) Define “alg”:”dir” (direct) to mean that the symmetric key is directly used as the CMK for the block encryption and integrity calculations, rather than as a key to wrap the CMK value.
>  
> (b) Define “alg”:”ECDH-ES+A128KW” and “alg”:”ECDH-ES+A256KW” to mean that the result of the key agreement is respectively used as the 128 bit or 256 bit AES Key Wrap key to wrap the CMK.
>  
> Doing this will enable all four flavors, whereas we’re currently missing 2 and 3 below:
> I recognize that flavors 2 and 4 are not usable with multiple recipients when methods such as JWE JSON Serialization are used (which counts on a common CMK value to enable a common ciphertext value).  A note to that effect would be added to the JWA definitions of “alg”:“ECDH-ES” and “alg”:”dir” and it would be pointed out in the JWE-JS spec that “alg” values that utilize a separate CMK MUST be used when the plaintext is encrypted to multiple recipients.
>  
> Comments?
>  
>                                                                 -- Mike
>  
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Edmund Jay <[email-masked]>
Date: Thu, 19 Jul 2012 13:57:22 -0700 (PDT)

The proposal is fine as long as it's made clear that cases 2 and 4 are not 
useable for multiple recipient scenarios.

-- Edmund

________________________________
From: Mike Jones <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Wed, July 18, 2012 6:04:14 PM
Subject: [jose] Symmetric encryption and key agreement with and without a 
separate CMK

Hi all,
 
I’ve been thinking about two of our open issues, which are closely related, and 
am writing to make a proposal to resolve both of them.  The issues are:
 
(1) Currently we specify methods for using symmetric keys to key wrap a separate 
Content Master Key (CMK), but no means of using the symmetric key as the CMK 
directly.  Some applications need this functionality, both for size and for 
efficiency  reasons.
 
(2) Currently we specify methods for performing key agreement and directly using 
the resulting key as the CMK to perform block encryption, but no means of using 
the agreed-upon key to wrap a separate CMK.  When doing key agreement for 
multiple  recipients, a separate CMK is needed.
 
Thus, I propose that we define methods for filling in both of the holes above, 
as follows:
 
(a) Define “alg”:”dir” (direct) to mean that the symmetric key is directly used 
as the CMK for the block encryption and integrity calculations, rather than as a 
key to wrap the CMK value.
 
(b) Define “alg”:”ECDH-ES+A128KW” and “alg”:”ECDH-ES+A256KW” to mean that the 
result of the key agreement is respectively used as the 128 bit or 256 bit AES 
Key Wrap key to wrap the CMK.
 
Doing this will enable all four flavors, whereas we’re currently missing 2 and 3 
below:
 
I recognize that flavors 2 and 4 are not usable with multiple recipients when 
methods such as JWE JSON Serialization are used (which counts on a common CMK 
value to enable a common ciphertext value).  A note to that effect would be 
added  to the JWA definitions of “alg”:“ECDH-ES” and “alg”:”dir” and it would be 
pointed out in the JWE-JS spec that “alg” values that utilize a separate CMK 
MUST be used when the plaintext is encrypted to multiple recipients.
 
Comments?
 
                                                                -- Mike

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 19 Jul 2012 21:45:02 +0000

>> I recognize that flavors 2 and 4 are not usable with multiple recipients when methods such as JWE JSON Serialization are used (which counts on a common CMK value to enable a common ciphertext valu…

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: John Bradley <[email-masked]>
Date: Thu, 19 Jul 2012 15:57:57 -0600

Sorry I missed your post.  I will have a look.  

The idea with 1 is that it allows for the rotation of the key for the stream cypher without the need to negotiate new shared secrets. 

What bothers you about it. 

We can meet up in Vancouver if you are coming 

John B. 

Sent from my iPad

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Jul 2012 22:07:39 +0000

Matt, if you look at the examples in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.1 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.2, you'll see that the encrypted key occupies more than half the total space of the JWE in those examples - 342 characters out of 597 and 475 respectively, to be precise.  That's a big deal when operating in space-constrained environments, such as passing JWTs as URI query parameters - where the total URL length is often limited to 2048 characters or sometimes less.  Plus there's a significant performance advantage in not having to do the keygen for the CMK or two encryptions, rather than one.  The direct encryption mode may not be for everyone, but for those that need it, it can be the difference between meeting space and performance budgets, or not.

Like John, I'd be glad to talk with you about this in Vancouver.

				Best wishes,
				-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Thursday, July 19, 2012 2:58 PM
To: Matt Miller (mamille2)
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK

John B. 

Sent from my iPad

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jul 2012 15:21:03 -0700

As an implementor, I would like to transport multiple symmetric encrypted tokens in less than 2000 bytes.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 20 Jul 2012 16:56:45 +1000

Keep #1; add #3; drop #4; and maybe add #2, but not with an “alg”:”dir” hack.

#4 (key agreement result used as the CMK) saves ~50 chars (or 24 chars?) compared to #3, but only when you have used hundreds of chars (probably doube-base64-encoded) to represent an ephemeral key. Not sure it is worthwhile.

The “alg”:”dir” hack is making Richard Barnes’s JSMS ideas look better and better (if it didn’t drop the authenticatedAttributes part of CMS).

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, 19 July 2012 11:04 AM
To: [email-masked]
Subject: [jose] Symmetric encryption and key agreement with and without a separate CMK

Hi all,

Comments?

                                                                -- Mike

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Jul 2012 09:56:40 -0400

FWIW, I wouldn't be all that opposed to adding back in the authenticatedAttributes.  

I also note that this all becomes unnecessary if you can just have one wrapped key value for many encrypted objects.  That works fine in JSMS using detached encryption info: 

[tiny-encrypted-body-1], ..., [tiny-encrypted-body-n], 
{
  "type": "EncryptedData",
  "algorithm": {name:"aes128-gcm", iv:"ZONce...lU-g"}
  "keys": /* wrapped keys */
}

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Jul 2012 17:48:26 +0000

The reason we already have #4 (direct use of the agreed-upon key) is that it saves an unnecessary second encryption step in the single recipient case.  There is also some space advantage as well, as you point out.

Do you have an alternative syntax proposal to “alg”:”dir” for expressing direct symmetric encryption, since apparently you don’t like that syntax?  Several others have said that it would work for them…

                                                            Thanks,
                                                            -- Mike

From: Manger, James H [mailto:[email-masked]]
Sent: Thursday, July 19, 2012 11:57 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] Symmetric encryption and key agreement with and without a separate CMK

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Thursday, 19 July 2012 11:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Symmetric encryption and key agreement with and without a separate CMK

Hi all,

Comments?

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 20 Jul 2012 14:40:55 -0700

It seems like the correct think should be “alg”:”none” J

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, July 20, 2012 10:48 AM
To: Manger, James H; [email-masked]
Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK

                                                            Thanks,

                                                            -- Mike

--

James Manger

Hi all,

Comments?

                                                                -- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 20 Jul 2012 21:51:25 +0000

“none” is not informative ☹ at all, at least the “dir” is telling us something

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, July 20, 2012 2:41 PM
To: Mike Jones; 'Manger, James H'; [email-masked]
Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK

It seems like the correct think should be “alg”:”none” ☺

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Friday, July 20, 2012 10:48 AM
To: Manger, James H; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK

                                                            Thanks,
                                                            -- Mike

From: Manger, James H [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, July 19, 2012 11:57 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Symmetric encryption and key agreement with and without a separate CMK

--
James Manger

Hi all,

Comments?

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Jul 2012 21:53:49 +0000

Yes, I’d considered “none”, but rejected it for several reasons.  First, “none” is a JWS algorithm – not a JWE algorithm.  It also means something completely different than “none” used in the JWS case, so it’s better not to overload the value and introduce confusion, both for humans, and in implementations.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Friday, July 20, 2012 2:51 PM
To: Jim Schaad; Mike Jones; 'Manger, James H'; [email-masked]
Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Jim Schaad
Sent: Friday, July 20, 2012 2:41 PM
To: Mike Jones; 'Manger, James H'; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK

                                                            Thanks,
                                                            -- Mike

--
James Manger

Hi all,

Comments?

                                                                -- Mike

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 23 Jul 2012 13:27:47 +1000

Mike,

> (a) Define “alg”:”dir” (direct) to mean that the
>     symmetric key is directly used as the CMK for
>     the block encryption and integrity calculations,
>     rather than as a key to wrap the CMK value.

> Do you have an alternative syntax proposal to "alg":"dir"
> for expressing direct symmetric encryption,
> since apparently you don’t like that syntax?
> Several others have said that it would work for them…

The current JWS/JWE model puts the "primary" algorithm in the "alg" field. You determine how to process the message by determining what sort of algorithm the "alg" value is.
With this model, direct encryption with a pre-established symmetric key should put the AEAD algorithm in the "alg" field. That is, rename the "enc" field to "alg" when doing encryption directly with a pre-established symmetric key.
Example: {"alg":"A256GCM", …}

I think it would be better to have a dedicated field (eg "t") to specify the mode (eg "t":"sig" for with a digitally signed message). For direct symmetric encryption define a new mode value, eg "t":"enc". 
Example: {"t:"enc", "enc":"A256GCM", …}

--
James Manger