On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <[email protected]>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. > As I said to John, that is not an acceptable solution because it breaks the XMPP use case. The minimum sensible change is to remove the per-recipient info from the integrity check. --Richard > > 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 >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
