Re: [jose] Field Matrix

[Richard Barnes <[e-mail]>]

Compress(plaintext) and Plaintext have the same information content.  So
the attacker hasn't revealed anything.  Still not a security risk.

--Richard


On Thu, Jun 27, 2013 at 11:43 AM, Peck, Michael A <[e-mail]> wrote:

>  “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]>
> 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****
>
>  ****
>
>  ****
>
> ** **
>