FWIW, as an implementor, I would like the headers protected. I don't require multiple recipients.
On Apr 25, 2013, at 3:42 PM, Mike Jones <[email protected]> wrote: > As background on the decision to integrity protect the headers – this didn’t > come out of a vacuum. The JWT designers sought out Ben Laurie’s advice in > 2010 and he’d suggested that the best thing would be to protect everything. > Indeed, Ben restated exactly the same position in a CRFG discussion on the > topic earlier this month, writing “Why even discuss these? What is wrong with > the answer "all parameters should be protected"?”. > > Ben’s not the only one who believes that it’s appropriate to protect the > metadata. For instance, the abstract of RFC 6211 “Cryptographic Message > Syntax (CMS) Algorithm Identifier Protection Attribute” begins “The > Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is > vulnerable to algorithm substitution attacks”. Like RFC 6211 does for CMS, > some would also like to prevent those attacks for JOSE. > > Best wishes, > -- Mike > > From: Richard Barnes [mailto:[email protected]] > Sent: Thursday, April 25, 2013 2:46 PM > To: Russ Housley > Cc: Mike Jones; [email protected] > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > 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
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
