Re: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

["Manger, James" <[e-mail]>]

Mike, thanks for trying to explain with a page of Security Considerations the ambiguity arising since existing (OLD) JWS implementations will silently ignore the "b64":false signal.

It is still wrong. The extra text starts by saying "there is no security problem... since the signature will fail" when "b64":false is ignored, but then ends by saying "crit":["b64"] is necessary when "b64":false is ignored. It cannot be both!

   There is no security problem if a JWS correctly created using "b64"
   with a "false" value is received by an implementation not supporting
   the "b64" Header Parameter, since the signature will fail to verify
   and the JWS will therefore be rejected.
  ...
   Only if the application dynamically switches between "false" and
   "true" values for "b64" (something NOT RECOMMENDED in Section 6),
   would it be necessary for the application to require the use of
   "crit" with a value of "["b64"]" in such application contexts.


The signature can, in fact, still verify when "b64":false is ignored - giving the verifier the wrong content.
We could have chosen a different signing input to avoid all ambiguity, but decided against that (as it was aesthetically nice to keep a lower-layer invariant somewhere inside JWS implementations of signing-up-to-the-2nd-dot).
We could have required "crit":["b64"], but would prefer to avoid the extra handful of bytes (and probably aren't that confident that everyone implements "crit" properly anyway).
We could leave it to users to avoid the ambiguity at higher layers by having totally separate contexts that do & don't use "b64":false, trying to help them get it right with advice about "application profiles", "application context", a "NOT RECOMMENDED", and 5 extra Security Considerations paragraphs (though what "application" means here is not that clear).

To me, this is a design failure.



The extra text about trust is dangerous.

   If the trust established by
   verifying the signer's key does not actually establish that the
   creator is a trusted party, then this case in which JWS libraries
   supporting and not supporting the extension may respectively
   interpret the attacker's payload as being encoded or unencoded is the
   least of the application's worries.

CAs issuing certificates to millions of HTTPS web sites (used to verify the signer's key) absolutely DO NOT establish that the creator (web site) is a trusted party, merely what the creator's name is. Misinterpreting what a signer means is bad regardless of trust.

--
James Manger


From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Thursday, 12 November 2015 2:37 AM
To: [e-mail]
Subject: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

Draft -04 of the JWS Unencoded Payload Option specification addresses the shepherd comments.  Thanks to Jim Schaad for his careful review.  The primary change was adding additional security considerations text, including describing when "crit" should be used.

The specification is available at:

*         https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-04

An HTML formatted version is also available at:

*         http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-04.html

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1474 and as @selfissued<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d>.