Yes, if the application is willing to accept the horrendous inefficiency of double-base64 encoding.
Again, arbitrary and capricious restriction in the name of a non-existent security benefit. --Richard On Thu, Apr 25, 2013 at 6:46 PM, Mike Jones <[email protected]>wrote: > Applications are now free to add their own AAD information to the JWE > header, now that not-understood header parameters must be ignored.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, April 25, 2013 2:51 PM > *To:* John Bradley > *Cc:* Mike Jones; Jim Schaad; [email protected] > > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > ** ** > > On Thu, Apr 25, 2013 at 4:40 PM, John Bradley <[email protected]> wrote:** > ** > > For multiple recipients using GCM with a single CEK and IV we can > logically have 0 AAD segments or 1 AAD segment.**** > > ** ** > > That is just the reality of the situation. **** > > ** ** > > I would also note that taking the JOSE overhead out of the AAD segment > frees it up for the application to use.**** > > ** ** > > **** > > One possible solution is to the GCM issue is to have 1 AAD segment > containing the envelope information for all recipients.**** > > I understand for people wanting 0 AAD segments that will not be there > first choice.**** > > ** ** > > The downside of this is that you can't incrementally add recipients, they > all need to be known upfront to include the info in the AAD.**** > > ** ** > > What I don't know is if there is really any compelling use-case for > incremental addition of recipients without re-encrypting (changing the IV > atleast)**** > > ** ** > > The XMPP use case is precisely this. When the sender encrypts the > message, it doesn't know the set of public keys that it's sending it to.** > ** > > ** ** > > So the only other possible alternative is taking the per-recipient info > out of the integrity check. But if we're going to do that, we might as > well go all the way and get rid of the integrity check altogether. > Applications that want to integrity protect information can put it in the > AAD segment on their own. **** > > ** ** > > --Richard**** > > ** ** > > ** ** > > **** > > ** ** > > John B.**** > > . **** > > ** ** > > On 2013-04-25, at 4:14 PM, Mike Jones <[email protected]> wrote: > **** > > > > **** > > Hi Richard,**** > > **** > > Actually, there are four goals in play:**** > > **** > > 1. GCM**** > > 2. Efficient encoding for multiple recipients**** > > 3. Header integrity protection**** > > 4. Independent protection of each recipient’s headers**** > > **** > > Per my response to Russ, by giving up 4, we can achieve 1, 2, and 3. > (Credit goes to John Bradley for this solution.)**** > > **** > > -- Mike**** > > **** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, April 25, 2013 11:14 AM > *To:* Mike Jones > *Cc:* Jim Schaad; [email protected] > *Subject:* Re: [jose] I-D Action: > draft-ietf-jose-json-web-encryption-09.txt**** > > **** > > Mike, **** > > **** > > Your facts are right, but your conclusions are wrong.**** > > **** > > We have three mutually incompatible goals here:**** > > 1. GCM**** > > 2. Efficient encoding for multiple recipients**** > > 3. Header integrity**** > > **** > > We can have any two of these, but not all three. If we try to do all > three (JWE-08), then we end up with the vulnerability identified in the > CFRG thread. So we need to choose which one to get rid of.**** > > **** > > Getting rid of GCM is clearly not the right answer, as evidenced by the > reaction in this thread. There are clear, concrete use reasons to support > multiple recipients, but not for header integrity. And header integrity > can be "polyfilled" with an optional feature, for those who are willing to > break the multiple recipient case. Clearly, header integrity is the > weakest link here.**** > > **** > > JWE-09 is the reductio ad absurdum of header integrity. Let's do the > logical thing and stop the absurdity.**** > > **** > > --Richard**** > > **** > > **** > > **** > > On Thu, Apr 25, 2013 at 2:48 AM, Mike Jones <[email protected]> > wrote:**** > > Jim - I am surprised that you would say that my co-authors Eric Rescorla > or Joe Hildebrand or the working group would advocate using AES GCM in a > way that would result in severe security vulnerabilities - in particular, > allowing attackers to obtain the XOR of the messages to multiple recipients > encrypted using GCM - a vulnerability identified by the CFRG. > > Not stating this in the document would seem to me to be highly > irresponsible, given the brittleness of GCM in this regard, as identified > by the CRFG. As I said to Richard Barnes over dinner last night, while > unpleasant, and possibly surprising to those who aren't familiar to how GCM > actually works, as an editor, I viewed including the statement that "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" as necessary, and > "truth in advertising". > > -- Mike**** > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Jim Schaad > Sent: Wednesday, April 24, 2013 9:07 PM > To: Mike Jones > Cc: [email protected] > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt > > 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-0 > > 9 > > > > > > 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
