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
