Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Yaron Sheffer [mailto:[e-mail]]
> Sent: Thursday, December 04, 2014 1:08 PM
> To: ? Matt Miller; IETF Security Directorate; The IESG; draft-ietf-jose-
> [e-mail]
> Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06
> 
> Hi Matt,
> 
> Please see my comments below. I have removed much of the original text,
> and only left points that need further discussion.
> 
> Thanks,
> 	Yaron
> 
> On 12/03/2014 12:02 AM, ? Matt Miller wrote:
> [...]
> 
> >
> >>   5.3.5: In the General Serialization version, I don't understand
> >> why only the encrypted key is per-recipient. I would expect the
> >> PBES2 parameters too (e.g., the salt)  to be per-recipient.
> >> Presumably each of them is using a different password, and there's
> >> no reason to use a common salt. Similarly in 5.4.5.
> >>
> >
> > For compatibility across serializations (compact, general JSON,
> > flattened JSON), all of the parameters need to be in the JWE Protected
> > Header.  In the general serialization, that means only the
> > "encrypted_key" field is present for the (presumably) sole recipient.
> >
> > Would it be acceptable if the following were added to 5.3?
> >
> >     Note that if password-based encryption is used for multiple
> >     recipients, it is expected that each recipient use different
> >     values for the PBES2 parameters "p2s" and "p2c".
> >
> 
> So I still don't understand: don't we need an example that demonstrates
> how the JSON structure (or multiple structures) is generated so that
> "each recipient use(s) different values"?

It is not clear to me what you are asking for at this point.    Section 5.13 has a demonstration of how to deal with multiple recipients for a set of key management algorithms, but for every different type of key management that is possible.   It is not clear to me that a password based encryption is a good place to show multiple recipients.  

The JWE specification allows for three different locations for parameters to be placed.  Any parameter can go in any of these different locations and they are all treated differently.  There are rules that a parameter of any given name cannot occur in two different locations, this means that if one did have multiple recipient situations, that parameters which have the same name but are different would be forced into the unprotected bag of the per recipient location.  This would be true for any of the different parameters - the most common would the 'alg' parameter which is generally different for each recipient.

> 
> In general I don't understand this "compatibility" thing. Obviously
> there are some cases that cannot be expressed in all serialization
> types. Otherwise why would we need three of them?

I will assume that you have read (or at least scanned) section 7 of the JWE document.   However a summary of it is:

* Compact serialization does not support either the global or per recipient unprotected parameter bag
* Compact serialization does not support application AAD information.
* Compact serialization and Flattened JSON serialization only support one recipient

Since the document is attempting to show all three serializations where possible, this does impose a restriction on where parameters can be placed.

> 
> >>   5.7: same as above, it makes sense for the per-recipient key to
> >> have an ID, rather than the content encryption key (typically an
> >> ephemeral key). And then that ID should be in the per-recipient
> >> data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a
> >> syntax for multiple recipients that's inconsistent with the
> >> single-recipient case, which would make sense if we got rid of the
> >> array.
> >>
> >
> > For compatibility across serializations (compact, general JSON,
> > flattened JSON), all of the parameters need to be in the JWE Protected
> > Header.  Also, the mixing of "recipients" and "encrypted_key"/"header"
> > in the top-level object is not permitted for the general serialization.
> >
> 
> Still confused. Sorry.

This has the same basic response.

The protected parameter bag is not associated with the content encryption key.  It applies equally to the content encryption key and the recipient key.  A parameter such as kid is defined as only applying to a CEK in the direct encryption case (which can be argued is the recipient key).  In all other cases the kid parameter always applies to the recipient key and not to the CEK.  You cannot make an association of keys and location of attributes.

> 
> >>   5.11: this example seems strange to me - why would anybody NOT
> >> want to integrity-protect the key ID and algorithm? I would prefer
> >> a more realistic example, or failing that, a recommendation to
> >> developers to avoid this practice. Similarly 5.12, which is an even
> >> worse idea.
> >>
> >
> > Integrity protection was thoroughly discussed in the JOSE WG.  While
> > there are some limited attacks possible when some parameters are
> > unprotected, the WG felt there were enough use cases where these
> > attacks are mitigated through other means that integrity protection of
> > the part of all of the header is not always required.
> 
> So (personal opinion here) I think the WG took a security risk that
> should not have been taken in 2014, for a minor performance gain. We
> have seen too many protocols fail because of integrity-protection
> shortcuts. Who would have thought you need to integrity-protect the
> padding field! The fact that CMS took this route back in 1999 is sort of
> irrelevant, as we've all learned a lot since then.

Allowing for integrity protection of kid and algorithm would have ended up with a very different looking structure than what we had.  This was the approach that was going to be used by the authors of the draft and was universally and roundly rejected by the WG.   If that is really what you want to do, then one might as well create n messages each for one recipient and protected the parameters in that way rather than create a multi-recipient message.  The final effect is going to be the same as either one needs to have a very complex structure of the protected structure where every recipient is included there (and thus force a full re-encryption by anybody changing the set of recipients) or each recipient has to be done independently in order to create a MAC value just for that recipient.  Neither of these approaches is very appetizing. 

How would you go about doing such a design to make it so that only a single encryption process is needed, and so that one can add new recipients without having to do a full decrypt and re-encrypt if one wants to either add or strip recipients from a message?

If full integrity protection is needed, one can always do a single message per recipient.   However, changing something like the kid is not currently very useful.  The fact that one finds the wrong key is much less of an attack (other than a DOS attack) with authenticated encryption that it was before with normal symmetric encryption.  Failing to successfully decrypt a message is not a huge attack vector that the WG cared about given that it can be accomplished by just changing one byte in the cipher text as well.

Jim