Subject: [jose] Feedback on dropping "sph" header parameter

From: Mike Jones <[email-masked]>
Date: Sat, 25 Jul 2015 04:12:51 +0000

Multiple people have given feedback that they're uncomfortable with the "sph":false option in https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00.  Martin Thompson's review<http://www.ietf.org/mail-archive/web/jose/current/msg05158.html> expressed reservations similar to those raised at the microphone during the ACME meeting in Prague, and similar to those John Bradley shared with me there in person.

The gist of this security argument is as follows...  Assume you have an encoded protected header value H in which "sph":false is not present and a payload P.  Let S be the JWS Signature of H || "." || P,

Now, construct a new payload P' := H || "." || P.  The JWS Signature of P' when using "sph":false is also equal to S.  Being able to generate the same signature for two payloads, one of which adds a prefix to the other, seems like a potential security issue.

(I *believe* that the JWS JSON Serialization's unprotected headers don't introduce that problem because the "." is still always included in the JWS Signing Input, thus delimiting the headers and the payload.)

Another objection to "sph" was raised by Matias Woloski<http://www.ietf.org/mail-archive/web/jose/current/msg05191.html>, who stated that including "sph" seemed like a premature optimization.

The rationale for having "sph":false is that for massive payloads, it may be an important performance optimization not to have to malloc a buffer big enough to hold the concatenation of the protected headers and the payload and copy them to the buffer - only for the purpose of calling the sign() function on the concatenation.  If you can call sign() on the bare payload you already have, you never have to copy it.  "sph":false with "b64":false enables this.

What do you think?  Should "sph" stay or should it go?

                                                            -- Mike

---

From: John Bradley <[email-masked]>
Date: Sat, 25 Jul 2015 11:04:17 +0200

I think dropping it and letting the implementations decide how to deal with the buffer issue, is best.   I don’t think it is a good tradeoff unless there is no way for implementations to deal with it.

John B.

> On Jul 25, 2015, at 6:12 AM, Mike Jones <[email-masked]> wrote:
> 
> Multiple people have given feedback that they’re uncomfortable with the “sph”:false option inhttps://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00 <https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00>.  Martin Thompson’s review <http://www.ietf.org/mail-archive/web/jose/current/msg05158.html> expressed reservations similar to those raised at the microphone during the ACME meeting in Prague, and similar to those John Bradley shared with me there in person.
>  
> The gist of this security argument is as follows...  Assume you have an encoded protected header value H in which “sph”:false is not present and a payload P.  Let S be the JWS Signature of H || “.” || P,
>  
> Now, construct a new payload P’ := H || “.” || P.  The JWS Signature of P’ when using “sph”:false is also equal to S.  Being able to generate the same signature for two payloads, one of which adds a prefix to the other, seems like a potential security issue.
>  
> (I *believe* that the JWS JSON Serialization’s unprotected headers don’t introduce that problem because the “.” is still always included in the JWS Signing Input, thus delimiting the headers and the payload.)
>  
> Another objection to “sph” was raised by Matias Woloski <http://www.ietf.org/mail-archive/web/jose/current/msg05191.html>, who stated that including “sph” seemed like a premature optimization.
>  
> The rationale for having “sph”:false is that for massive payloads, it may be an important performance optimization not to have to malloc a buffer big enough to hold the concatenation of the protected headers and the payload and copy them to the buffer – only for the purpose of calling the sign() function on the concatenation.  If you can call sign() on the bare payload you already have, you never have to copy it.  “sph”:false with “b64”:false enables this.
>  
> What do you think?  Should “sph” stay or should it go?
>  
>                                                             -- Mike
>  
> _______________________________________________
> jose mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>

---

From: Brian Campbell <[email-masked]>
Date: Sat, 25 Jul 2015 14:10:10 +0200

I'm in favor of dropping "sph"

On Sat, Jul 25, 2015 at 11:04 AM, John Bradley <[email-masked]> wrote:

> I think dropping it and letting the implementations decide how to deal
> with the buffer issue, is best.   I don’t think it is a good tradeoff
> unless there is no way for implementations to deal with it.
>
> John B.
>
> Multiple people have given feedback that they’re uncomfortable with the
> “sph”:false option in
> https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00.
>  Martin Thompson’s review
> <http://www.ietf.org/mail-archive/web/jose/current/msg05158.html> expressed
> reservations similar to those raised at the microphone during the ACME
> meeting in Prague, and similar to those John Bradley shared with me there
> in person.
>
> The gist of this security argument is as follows...  Assume you have an
> encoded protected header value H in which “sph”:false is not present and a
> payload P.  Let S be the JWS Signature of H || “.” || P,
>
> Now, construct a new payload P’ := H || “.” || P.  The JWS Signature of P’
> when using “sph”:false is also equal to S.  Being able to generate the same
> signature for two payloads, one of which adds a prefix to the other, seems
> like a potential security issue.
>
> (I **believe** that the JWS JSON Serialization’s unprotected headers
> don’t introduce that problem because the “.” is still always included in
> the JWS Signing Input, thus delimiting the headers and the payload.)
>
> Another objection to “sph” was raised by Matias Woloski
> <http://www.ietf.org/mail-archive/web/jose/current/msg05191.html>, who
> stated that including “sph” seemed like a premature optimization.
>
> The rationale for having “sph”:false is that for massive payloads, it may
> be an important performance optimization not to have to malloc a buffer big
> enough to hold the concatenation of the protected headers and the payload
> and copy them to the buffer – only for the purpose of calling the sign()
> function on the concatenation.  If you can call sign() on the bare payload
> you already have, you never have to copy it.  “sph”:false with “b64”:false
> enables this.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 27 Jul 2015 04:58:10 +0900

I am fine as well but I am curious to hear the opinion of the person who
proposed it.

On Saturday, July 25, 2015, Brian Campbell <[email-masked]>
wrote:

> On Sat, Jul 25, 2015 at 11:04 AM, John Bradley <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> On Jul 25, 2015, at 6:12 AM, Mike Jones <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>> https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00
>> .  Martin Thompson’s review
>> Now, construct a new payload P’ := H || “.” || P.  The JWS Signature of
>> P’ when using “sph”:false is also equal to S.  Being able to generate the
>> same signature for two payloads, one of which adds a prefix to the other,
>> seems like a potential security issue.
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Mike Jones <[email-masked]>
Date: Sun, 26 Jul 2015 20:14:28 +0000

I defined “sph” based on a conversation I’d had earlier with Matt Miller about a use case he has with huge payloads in a browser application.  He’d told me that having to do the allocate and copy could be a significant performance hit.  However, I followed up with Matt in Prague, and it turns out that his application is encrypting the content – not signing it.  So the JWS Signing Input Options spec doesn’t apply to it.

                                                            -- Mike

From: Nat Sakimura [mailto:[email-masked]]
Sent: Sunday, July 26, 2015 12:58 PM
To: Brian Campbell
Cc: John Bradley; Mike Jones; [email-masked]
Subject: Re: [jose] Feedback on dropping "sph" header parameter

I am fine as well but I am curious to hear the opinion of the person who proposed it.

On Saturday, July 25, 2015, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
I'm in favor of dropping "sph"

On Sat, Jul 25, 2015 at 11:04 AM, John Bradley <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
I think dropping it and letting the implementations decide how to deal with the buffer issue, is best.   I don’t think it is a good tradeoff unless there is no way for implementations to deal with it.

John B.

On Jul 25, 2015, at 6:12 AM, Mike Jones <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

Multiple people have given feedback that they’re uncomfortable with the “sph”:false option inhttps://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2b50KVTBqod7N9hI%2bGLe6UoGCvXpUVnqXv1vV277xXiU%3d>.  Martin Thompson’s review<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I426zdg%2fj4QhCDajn6DsF9oPfXKd3fzO3Yy0oMymYzo%3d> expressed reservations similar to those raised at the microphone during the ACME meeting in Prague, and similar to those John Bradley shared with me there in person.

Another objection to “sph” was raised by Matias Woloski<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B2xKzGMLIpeMOwDLCWlmsbutNcfLBuFUcadzeEStG5I%3d>, who stated that including “sph” seemed like a premature optimization.

                                                            -- Mike

_______________________________________________
jose mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rk1ulDqmu8%2fAFXq6itfdRPHzi9m%2fi5T2ML8uQ3XLNR0%3d>

_______________________________________________
jose mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rk1ulDqmu8%2fAFXq6itfdRPHzi9m%2fi5T2ML8uQ3XLNR0%3d>

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DawUq1rv%2ffF2A0LNzcU67SeBQnbY8s6RMCheoCSV3e0%3d>
@_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 27 Jul 2015 05:16:06 +0900

Thanks for the clarification.

Then it would be fine to remove it.

Nat

On Sunday, July 26, 2015, Mike Jones <[email-masked]> wrote:

>  I defined “sph” based on a conversation I’d had earlier with Matt Miller
> about a use case he has with huge payloads in a browser application.  He’d
> told me that having to do the allocate and copy could be a significant
> performance hit.  However, I followed up with Matt in Prague, and it turns
> out that his application is encrypting the content – not signing it.  So
> the JWS Signing Input Options spec doesn’t apply to it.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Sunday, July 26, 2015 12:58 PM
> *To:* Brian Campbell
> *Cc:* John Bradley; Mike Jones; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [jose] Feedback on dropping "sph" header parameter
>
>
>
> On Saturday, July 25, 2015, Brian Campbell <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2b50KVTBqod7N9hI%2bGLe6UoGCvXpUVnqXv1vV277xXiU%3d>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I426zdg%2fj4QhCDajn6DsF9oPfXKd3fzO3Yy0oMymYzo%3d> expressed
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B2xKzGMLIpeMOwDLCWlmsbutNcfLBuFUcadzeEStG5I%3d>,
> who stated that including “sph” seemed like a premature optimization.
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rk1ulDqmu8%2fAFXq6itfdRPHzi9m%2fi5T2ML8uQ3XLNR0%3d>
>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rk1ulDqmu8%2fAFXq6itfdRPHzi9m%2fi5T2ML8uQ3XLNR0%3d>
>
>
>
>
>
> --
> Nat Sakimura (=nat)
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DawUq1rv%2ffF2A0LNzcU67SeBQnbY8s6RMCheoCSV3e0%3d>
> @_nat_en
>
>
>