I suspect you are overstating the case:) It is hard to have per endpoint recipient information in the header when the sender doesn't know what the endpoints that are going to receive the JWE are before it sends it.
I would prefer to avoid using XMPP as a football for this. There is probably a better use case someplace that would show how a sender knowing beforehand the information for multiple recipients would encrypt the same plain text to all of them. Mostly what I would like to understand is if there is a real requirement for incremental encryption to new recipients after the fact using the same CMK & IV, or can the CMK & IV change for additional recipients. John B. On 2013-04-25, at 8:16 PM, Richard Barnes <[email protected]> wrote: > Again, this is because Matt has hacked around the current system to remove > per-recipient data from integrity protection. And the fact that you're OK > with that would mean that you would be OK with removing per-recipient data > from integrity protection in general, if you were to be logically consistent > ;) > > --Richard > > > On Thu, Apr 25, 2013 at 7:13 PM, John Bradley <[email protected]> wrote: > I agree with Matt. I don't think there is anything in the XMPP use case > that would break if the envelope is integrity protected. > I think there is only a single envelope anyway as I understand it. > > John B. > > On 2013-04-25, at 7:02 PM, Matt Miller <[email protected]> wrote: > > > > > On Apr 25, 2013, at 3:56 PM, Richard Barnes <[email protected]> > > wrote: > > > >> 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. > >> > > > > It is not clear to me how John's suggestion utterly breaks the XMPP use > > case, unless you have this alternate-reality version of XMPP-E2E you've not > > yet told me about (-: > > > > The current XMPP document already separates per-recipient info from the > > actual protected content. > > > > > > - m&m > > > > Matt Miller < [email protected] > > > Cisco Systems, Inc. > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
