I'm in favor of dropping "sph" On Sat, Jul 25, 2015 at 11:04 AM, John Bradley <[email protected]> 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 protected]> > wrote: > > 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 > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
