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

[John Bradley <[e-mail]>]

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