Hi Russ,

I agree that enabling GCM to be safely used in the multiple recipients case 
would be highly desirable.  It is currently prohibited because if the 
recipients share a common key and initialization vector (IV) but use different 
AAD values, this results in the identified vulnerability.  One possible 
solution that continues integrity protecting the headers but enables the safe 
use of GCM was identified off-list by John Bradley.
 
That solution is to have each recipient always use the same key, IV, and AAD 
values.  This could be accomplished by including all the header values in a 
single combined AAD value, rather than having the integrity protection for each 
recipient's headers be independent.

This change could be done in a manner that doesn't affect the computation for 
the single recipients case.  Given the upcoming interim JOSE meeting next week, 
and given the (understandable) strong negative reaction to the unusability of 
GCM with the current multiple recipients processing rules, I'll plan on quickly 
producing a draft -10 that changes the processing rules in the manner described 
above, so that idea can be concretely considered by the working group next week.

Just so people are clear on the properties on the new processing rules - this 
would mean that the integrity computations for each recipients would no longer 
be independent.  The only downside of this (which could be an upside in some 
ways) is that it would no longer be possible to add recipients over time 
without performing a new encryption computation with a new CEK and IV.

                                Cheers,
                                -- Mike

-----Original Message-----
From: Russ Housley [mailto:[email protected]] 
Sent: Thursday, April 25, 2013 10:31 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

Mike:

Like Jim, I cannot support this statement: AES GCM MUST NOT be used when using 
the JWE JSON Serialization for multiple recipients

All recipients ought to be performing decryption and integrity checking with 
the same GCM key.  The manner in which they obtain that key may be different 
(key transport: decrypt the GCM key with the recipient's private key, key 
agreement: agreement of a pairwise KEK and then unwrapping the GCM key with the 
KEK, pre-shared KEK: unwrapping the GCM key with the already known KEK, etc).

Russ


On Apr 25, 2013, at 12:07 AM, Jim Schaad wrote:

> Mike,
> 
> AES GCM MUST NOT be used when using the JWE JSON Serialization for
>   multiple recipients, since this would result in the same
>   Initialization Vector and Plaintext values being used for multiple
>   GCM encryptions.
> 
> I doubt your co-authors would agree with this.
> I doubt the working group with agree with this.
> I know that at least one co-chair does not agree with this I can 
> predict that the AD and IESG along with the security directorate would 
> crucify me if I allowed this to stand in the document..
> 
> Jim
> 
> 
> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf 
>> Of [email protected]
>> Sent: Tuesday, April 23, 2013 5:29 PM
>> To: [email protected]
>> Cc: [email protected]
>> Subject: [jose] I-D Action: 
>> draft-ietf-jose-json-web-encryption-09.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the Javascript Object Signing and 
>> Encryption Working Group of the IETF.
>> 
>>      Title           : JSON Web Encryption (JWE)
>>      Author(s)       : Michael B. Jones
>>                          Eric Rescorla
>>                          Joe Hildebrand
>>      Filename        : draft-ietf-jose-json-web-encryption-09.txt
>>      Pages           : 54
>>      Date            : 2013-04-23
>> 
>> Abstract:
>>   JSON Web Encryption (JWE) is a means of representing encrypted
>>   content using JavaScript Object Notation (JSON) data structures.
>>   Cryptographic algorithms and identifiers for use with this
>>   specification are described in the separate JSON Web Algorithms (JWA)
>>   specification.  Related digital signature and MAC capabilities are
>>   described in the separate JSON Web Signature (JWS) specification.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-09
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-
>> 09
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to