Subject: [jose] Field Matrix

From: "Jim Schaad" <[email-masked]>
Date: Thu, 20 Jun 2013 11:54:13 -0700

<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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 16:51:44 -0400

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 <[email-masked]> wrote:

> <no hat>****
> ** **
> think the following columns are probably of interest:****
>
> ** **
>
> Name, must understand, use required, common vs specific, protection
> required****
>
> ** **
>
> was specific – so it should be one location – and one was common – so it
> recipients.****
> ** **
> Do you have an idea of when this matrix might show up?****
>
> ** **
>
> Jim****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Jun 2013 21:01:40 +0000

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

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.

Jim

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 18:00:39 -0400

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 <[email-masked]>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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, June 20, 2013 1:52 PM
> *To:* Jim Schaad
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Field Matrix****
>
> ** **
>
> You can eliminate the "protection required" field, because there aren't
> any of those.  ****
>
> ** **
>
> fixed in the spec.****
> --Richard****
> On Thu, Jun 20, 2013 at 2:54 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> <no hat>****
>
>  ****
>
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: "Peck, Michael A" <[email-masked]>
Date: Thu, 27 Jun 2013 15:43:53 +0000

"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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, June 20, 2013 6:01 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Field Matrix

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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
There was a working group decision at the Denver meeting that "crit" must be integrity protected.  The reason for this is straightforward.

                                                                -- Mike

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

--Richard

Jim

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Jun 2013 18:25:44 -0400

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 <[email-masked]> 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****
>
> ** **
>
> *Sent:* Thursday, June 20, 2013 6:01 PM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked]
>
> There was no such decision.  Quoting directly from the minutes:****
>
> """****
>
> **  Crit Text****
>
> ** **
>
> be signed.****
> There was no consensus in the group at this time as we adjourned for the
> day****
>
> """****
>
> ** **
>
> possible to use "crit" safely without integrity protection.****
>
> ** **
>
> not a security compromise.****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> On Thu, Jun 20, 2013 at 5:01 PM, Mike Jones <[email-masked]>
> wrote:****
>
> There was a working group decision at the Denver meeting that “crit” must
> be integrity protected.  The reason for this is straightforward.****
>
>  ****
>