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

[Richard Barnes <[e-mail]>]

On Thu, Apr 25, 2013 at 6: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.
>


I reject your reality and substitute my own! [1]

In my preferred reality, XMPP E2E doesn't have to do the alg=dir hack that
it does now.  The base format will support multiple recipients cleanly
enough to support the XMPP case as well.

In any case, preventing incremental addition of recipients is an arbitrary
and capricious restriction in the name of a non-existent security benefit.

--Richard


[1] http://www.youtube.com/watch?v=W8qcccZy03s



>
>
> - m&m
>
> Matt Miller < [e-mail] >
> Cisco Systems, Inc.
>
>