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

[Richard Barnes <[e-mail]>]

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
>
>

Hey James,

Thanks for this.  I agree that Option 3 is a valid possibility, but not a
desirable one.

Option 2b is an interesting possibility.  Effectively, you would be
including a hash of the JWE (sans key) under the key wrap integrity check,
binding the key to the JWE.   I would note that we're already talking about
adding the ability to bind attributes to wrapped keys (for WebCrypto).  In
light of that, the "JWE digest" could just be included as one of those
attributes.

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.

So I think that lands us back at Option 2, with one more reason to make JWE
key wrapping the same as general key wrapping
[draft-barnes-jose-key-wrapping].

--Richard




> > ----------
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Richard Barnes
> > Sent: Wednesday, 3 April 2013 4:55 AM
> > …
> > The problem here is JWE, specifically the fact that the header (with
> > per-recipient data) is covered by the integrity check.  If you remove
> > the per-recipient data from the integrity check, then this problem goes
> > away.  In that case, there is only one invocation of GCM (not one per
> > recipient), so there's no problem.
> >
> > So the choice that JOSE faces is from the following options:
> >
> > Option 0. Outlaw GCM for multiple recipients.
> >   COST: GCM
> >
> > Option 1. Keep per-recipient info under integrity check, and require a
> > fresh nonce for each recipient
> >   COST: Removes all savings in the multiple recipient case
> >   BENEFIT: Doesn't break backward compatibility with current, single-
> > recipient JWE
> >
> > Option 2. Remove per-recipient info from integrity check
> >   COST: Breaks backward compatibility with current, single-recipient
> > JWE
> >   BENEFIT: Increases savings in multiple-recipient case (since no per-
> > recipient integrity check value)
> >
> > Option 0 is clearly not acceptable.  So basically, this is a choice
> > about how much we want to let deployed code keep us from sensible
> > architecture.
> >
> > To me, the choice is clear.  Changing code is minor, short-term pain.
> > Getting architecture wrong is major, long-term pain.  Let's do option
> > (2).
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>