Subject: Re: [jose] PBE salt should include alg id

From: Matt Miller <[email-masked]>
Date: Thu, 30 Jan 2014 11:15:25 -0700

On 11/7/13, 5:51 PM, Manger, James H wrote:
> JWA section 4.9 ?Key Encryption with PBES2? should follow the 
> recommendation of the PBES2 spec [RFC 2898 section 4.1 ?Salt?] by 
> including in the salt ?data that explicitly distinguishes between 
> different operations and different key lengths?.
> 
> 
> 
> We can do this quite easily in JWA by including the alg value (eg 
> ?PBES2-HS384+A192KW?) in the salt. I suggest:
> 
> 
> 
> salt = UTF8(alg) || 0x00 || BASE64URL_DECODE(p2s)
> 
> 
> 

When I read and interpreted that section, it came across as a
consideration for applications using PBES2 in JOSE.  I probably should
have pointed that out in my initial work on this.  C'est la vie.

That said, I personally don't have a problem with this change.
However, it does break existing implementations.  Given the stage
these drafts are in, it might be less disruptive to include
considerations and recommendations for applications.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Manger, James" <[email-masked]>
Date: Fri, 31 Jan 2014 11:58:09 +1100

> considerations and recommendations for applications.

Matt,

I'm not sure what you mean by "include considerations and recommendations for applications".
Do you mean JWA section 4.8.1.1. "p2s (PBES2 salt) Parameter" should say:
  "A salt MUST include 8 or more random octets, and can include the "alg" value"

I don't think that helps. The issue is that the JOSE *recipient* needs to ensure the correct "alg" value is in the salt.

Or are you suggesting app-specific profiles of JOSE can add a requirement:
  "A salt MUST include the "alg" value and 8 or more random octets. A recipient MUST confirm that the "p2s" value (after base64url-decoding) starts with the "alg" value."

That would theoretically work, except that it adds about 30 bytes to messages, is easily ignored, and is awkward to implement as it requires an app-specific rule to be enforced deep inside app-agnostic JOSE libraries.

"p2s" has only been in the drafts for 6 months.
Can't we fix it properly?

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Fri, 31 Jan 2014 01:09:30 +0000

Given that the PBE algorithms are recent additions that I don't believe have been widely deployed, I'm personally OK with making this change, if the consensus is that it's the right thing to do from a security perspective.

Thanks for bringing this to our attention, James.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Manger, James
Sent: Thursday, January 30, 2014 4:58 PM
To: Matt Miller; <[email-masked]>
Subject: Re: [jose] PBE salt should include alg id

Matt,

--
James Manger
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Jan 2014 06:45:45 -0700

As an implementor who's not yet implemented the PBE algorithms, I'm okay
with making changes to them (assuming WG consensus, of course).

On Thu, Jan 30, 2014 at 6:09 PM, Mike Jones <[email-masked]>wrote:

> Given that the PBE algorithms are recent additions that I don't believe
> have been widely deployed, I'm personally OK with making this change, if
> the consensus is that it's the right thing to do from a security
> perspective.
>
> I don't think that helps. The issue is that the JOSE *recipient* needs to
> ensure the correct "alg" value is in the salt.
>
>   "A salt MUST include the "alg" value and 8 or more random octets. A
> recipient MUST confirm that the "p2s" value (after base64url-decoding)
> starts with the "alg" value."
>
> That would theoretically work, except that it adds about 30 bytes to
> messages, is easily ignored, and is awkward to implement as it requires an
> app-specific rule to be enforced deep inside app-agnostic JOSE libraries.
>

---

From: Matt Miller <[email-masked]>
Date: Fri, 31 Jan 2014 11:30:57 -0700

On 1/30/14, 5:58 PM, Manger, James wrote:
>>> recommendation of the PBES2 spec [RFC 2898 section 4.1 ?Salt?]
>>> by including in the salt ?data that explicitly distinguishes
>>> between different operations and different key lengths?.
>>> 
>>> We can do this quite easily in JWA by including the alg value
>>> (eg ?PBES2-HS384+A192KW?) in the salt. I suggest:
>>> 
>> consideration for applications using PBES2 in JOSE.  I probably
>> should have pointed that out in my initial work on this.  C'est
>> la vie.
>> 
>> However, it does break existing implementations.  Given the
>> stage these drafts are in, it might be less disruptive to
>> include considerations and recommendations for applications.
> 
> 
> Matt,
> 
> I'm not sure what you mean by "include considerations and
> recommendations for applications". Do you mean JWA section 4.8.1.1.
> "p2s (PBES2 salt) Parameter" should say: "A salt MUST include 8 or
> more random octets, and can include the "alg" value"
> 
> I don't think that helps. The issue is that the JOSE *recipient*
> needs to ensure the correct "alg" value is in the salt.
> 
> Or are you suggesting app-specific profiles of JOSE can add a
> requirement: "A salt MUST include the "alg" value and 8 or more
> random octets. A recipient MUST confirm that the "p2s" value (after
> base64url-decoding) starts with the "alg" value."
> 
> That would theoretically work, except that it adds about 30 bytes
> to messages, is easily ignored, and is awkward to implement as it
> requires an app-specific rule to be enforced deep inside
> app-agnostic JOSE libraries.
> 
> "p2s" has only been in the drafts for 6 months. Can't we fix it
> properly?
> 
> -- James Manger
> 

I was suggesting that app-specific profiles can add a requirement, as
suits their needs -- maybe it's what you wrote, maybe it's something
else.  That's why I think there's two parts to that section in RFC 2898.

I don't think it requires app-agnostic libraries to enforce.  It does
require the application to enforce it's own policies, although how
awkward it is depends on how accessible this information out of the
JOSE library.

But this might all be moot if no one objects to the breaking change.

- -- 
- - m&m