Re: [jose] Field Matrix

["Peck, Michael A" <[e-mail]>]

"zip" indicates whether the authenticated encryption is applied to Plaintext vs Compress(Plaintext).

By stripping "zip" an attacker could make the message appear to successfully decrypt to Compress(Plaintext) rather than Plaintext?

I suppose whether that could lead to something bad would be implementation dependent, but anything that can lead to ambiguity about the contents of the original plaintext doesn't seem like a good idea.

Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Thursday, June 20, 2013 6:01 PM
To: Mike Jones
Cc: Jim Schaad; [e-mail]
Subject: Re: [jose] Field Matrix

There was no such decision.  Quoting directly from the minutes:
"""
**  Crit Text

Two questions were raised for dealing with the cirt field.  Does the crit field need to be signed and do the members listed in the crit field need to be signed.

There was no consensus in the group at this time as we adjourned for the day
"""

In order for the attack you describe to be an actual security risk, it would need to be the case that the parameters in "crit" were security-critical, as opposed to things that would simply cause incorrect processing.  One can certainly imagine parameters that would fall in the latter bin; my current favorite example is a "part" parameter that would allow fragmentation / reassembly.  Because such parameters exist, it's possible to use "crit" safely without integrity protection.

Can we at least agree that integrity protecting "zip" is unnecessary?  The only thing that stripping / changing "zip" causes is a processing failure, not a security compromise.

--Richard


On Thu, Jun 20, 2013 at 5:01 PM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
There was a working group decision at the Denver meeting that "crit" must be integrity protected.  The reason for this is straightforward.

If not integrity protected, an attacker could strip the "crit" field, defeating the semantic requirement that implementations must reject the input if a "crit" value is used that is not understood.  Thus, the spec requires that this field be integrity protected whenever used.

                                                                -- Mike

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Richard Barnes
Sent: Thursday, June 20, 2013 1:52 PM
To: Jim Schaad
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] Field Matrix

You can eliminate the "protection required" field, because there aren't any of those.

Or there shouldn't be: The only security case we have is algorithm dependent ("alg" must be protected if "alg" == "PS256", "PS512").  The only fields for which the specs currently require integrity protection are "zip" and "crit".  Neither of these have the property that changing them would cause a security violation, except in some application-dependent sense.  So the choice of integrity protection should be left to applications, not fixed in the spec.

--Richard

On Thu, Jun 20, 2013 at 2:54 PM, Jim Schaad <[e-mail]<mailto:[e-mail]>> wrote:
<no hat>

Having just started looking at a design implementation, I am now more than ever interested in seeing this matrix of fields.  At the present time I think the following columns are probably of interest:

Name, must understand, use required, common vs specific, protection required

I was just looking at the alg and enc fields for JWE and realized that one was specific - so it should be one location - and one was common - so it should be in a different location.  And then I needed to start thinking about where it goes in terms of compacted vs one recipient vs two recipients.

Do you have an idea of when this matrix might show up?

Jim