On Thu, Apr 25, 2013 at 5:45 PM, Russ Housley <[email protected]> wrote:
> 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.... > +much_more_than_one > > 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 >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
