Re: [jose] Field Matrix

[Richard Barnes <[e-mail]>]

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]>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]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, June 20, 2013 1:52 PM
> *To:* Jim Schaad
> *Cc:* [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]>
> 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****
>
>  ****
>
> ** **
>