Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-09.txt

[Matt Miller <[e-mail]>]

On Apr 25, 2013, at 3:56 PM, Richard Barnes <[e-mail]>
 wrote:

> On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones <[e-mail]>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 < [e-mail] >
Cisco Systems, Inc.