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

[John Bradley <[e-mail]>]

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 <[e-mail]> wrote:

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