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

["Jim Schaad" <[e-mail]>]

Mike,

 

I wish that we had talked about this last week at the F2F meeting.

 

This does not read like a security consideration, it read like an email that
is sent to the list saying that there is nothing to talk about here and it
can be completely ignored.  If that is the way that you feel about this, you
need to get census that there is no problem and kill the text.

 

How I would approach writing this consideration is as follows:

 

1.       Describe what the problem is.  While both James and I provided one
scenario that was easy to understand, it should not be thought of as the
only case that there is a problem.  The basic description of the problem is
that there are now two different strings that will generate the same
signature value, without there being a weakness in the hash algorithm.

2.      Describe the set of things that can be done to address this problem.

a.      Use the "crit" parameter

b.      Use a profile of the application that states there is only one
possible value

c.      Make sure that all implementations support the b64 parameter

 

Jim

 

 

 

 

 

From: jose [mailto:[e-mail]] On Behalf Of Manger, James
Sent: Wednesday, November 11, 2015 4:21 PM
To: Mike Jones <[e-mail]>; [e-mail]
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing shepherd
comments

 

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] <mailto:[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.ht
ml

 

                                                                -- 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.co
m%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d
47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2
bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d> .