Mike: If the header is protected with the AAD mechanism in GCM, then it must cover exactly the same bits for all recipients.
I do not see the need for JOSE header integrity. I have said this in the past. I'm saying it again.... Russ On Apr 25, 2013, at 3:09 PM, Mike Jones wrote: > 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
