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 > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
