Re: [jose] [Cfrg] GCM nonce reuse question

[Richard Barnes <[e-mail]>]

On Mon, Apr 15, 2013 at 11:50 AM, Matt Miller <[e-mail]> wrote:

>
> On Apr 15, 2013, at 9:25 AM, Richard Barnes <[e-mail]>
>  wrote:
>
> > On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <
> > [e-mail]> wrote:
> >
> >> I think there are more options for handling multiple recipients of
> >> AEAD-secured content:
> >>
> >>
> >> Option 3: Put all per-recipient info into one header; keep this header
> >> under the AEAD integrity check; have one nonce.
> >>  COST: All recipients need to be known (and their key exchange info
> >> created) before the AEAD algorithm is applied.
> >>  COST: The JWE JSON header structure needs to be adjusted (eg to have an
> >> array of recipient info) so it is not backward compatible with current
> >> drafts.
> >>  COST: Doesn't help use cases where one recipient forwards an
> >> AEAD-secured message on to a new recipient (eg an XMPP system receives a
> >> message secured for a user and re-secures it for a specific device of
> that
> >> user). Changing recipients requires reapplying the AEAD operations.
> >>  COST: Each recipient needs to see key exchange info of all recipients
> >> (privacy impact?).
> >>  POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is
> >> secured as a complete unit.
> >>
> >>
> >> Option 2b: Remove per-recipient info from AEAD integrity check; but add
> >> AEAD details to each key exchange. For instance, info about an AEAD
> >> operation (alg id, key id etc) potentially even including the whole
> >> ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT operation
> that
> >> encrypts the AEAD secret key for a recipient.
> >>  BENEFIT: The key exchange is tied to a specific AEAD operation.
> >>  COST: Crypto is not typically done like this; uncertain as to what
> exact
> >> security properties you are getting. Perhaps there are some
> similarities to
> >> NIST Concat KDF that adds "context" to key derivation: this adds
> "context"
> >> about an AEAD operation to the key exchange.
> >>
> >>
> >> I agree with Richard Barnes that the per-recipient key exchange details
> >> should be outside the AEAD operation (not covered by the AEAD integrity
> >> check). Go with option 2 or 2b.
> >> Then, separately, we can decide which details of the AEAD operation
> should
> >> be bound to each key exchange: none? AEAD key length? AEAD alg id? whole
> >> AEAD header? AEAD ciphertext? other context?
> >>
> >>
> >> --
> >> James Manger
> >>
> >>
> >
> > At the same time, this attribute should be optional, since I think there
> > are use cases where the CMK is not entirely ephemeral.  For example, I
> > think the current XMPP e2e document uses it as a session key rather than
> an
> > individual message key, so you wouldn't want to limit the key to a single
> > JWE.
> >
>
> XMPP e2e has both a session key and a per-message key. The per-message key
> is protected by the session key.
>
> That said, I also think Option 2 or 2b makes the most sense.
>
>
> - m&m
>
> Matt Miller < [e-mail] >
> Cisco Systems, Inc.
>


Thanks for the clarification.  I think the point stands, however, that the
"JWE-digest" attribute can be added as a protected attribute to the wrapped
key -- if we do wrapped keys right!

--Richard