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

From: "Manger, James" <[email-masked]>
Date: Thu, 12 Nov 2015 11:20:39 +1100

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:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, 12 November 2015 2:37 AM
To: [email-masked]
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>.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 12 Nov 2015 14:24:28 -0800

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:[email-masked]] On Behalf Of Manger, James
Sent: Wednesday, November 11, 2015 4:21 PM
To: Mike Jones <[email-masked]>; [email-masked]
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!

  .

 

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).

 

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:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, 12 November 2015 2:37 AM
To: [email-masked] <mailto:[email-masked]> 
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.

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

*
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> .

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Nov 2015 01:49:52 +0000

OK, I can take a stab at rewriting it that way.

It's not that I think there isn't ever a problem but I do think that there are lots of real cases in which there's only a problem if the producer is intentionally creating a JWS designed to confuse - in which case the producer is an attacker.  Do see any other cases in which there is a problem to address other than when the producer is intentionally emitting "b64":true but signing as if "b64" was false?

The current security considerations text was intended to do a case analysis of when there is and isn't a problem, breaking things down by who implements the extension and who doesn't.  In my analysis, if the recipient rejects a signature that it doesn't understand, I didn't consider that a security problem.  Do you agree with that?

While, yes, in retrospect I wish we'd talked about in person too, in fairness, I did write to the list in my November 2nd note that "I will add the thoughts above to the Security Considerations section", and that's what I did, keeping the factual content, but attempting to change the tone from e-mail conversational to factual.

But I'll try it your way instead, while also keeping the case analysis where appropriate.  In the meantime, please let me know your thoughts on the two questions I asked above.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 2:24 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

Mike,

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.

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.

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

Jim

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

--
James Manger

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

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 12 Nov 2015 18:02:33 -0800

Q1:  I would always assume that the producer is the attacker.  However, I
would not assume that the producer is using their own keys.  The producer
may be attempting to obtain the keys of a legitimate producer.  Production
in this case would also allow for a replay attack.  I think you did not
really mean to ask that question.  

I do believe that this attack vector can be used by a third party entity to
attack the system.  I do not know if that attack is going to make life a
tiny bit easier or a lot easier.

Q2:  Rejecting a message with a signature that does not validate is not a
security issue, setting aside the possible timing attacks.   However, I do
not believe that either James or myself claimed that this was going to
happen.  What we claimed was that there were going to be signatures that
were erroneously accepted.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, November 12, 2015 5:50 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd
comments

It's not that I think there isn't ever a problem but I do think that there
are lots of real cases in which there's only a problem if the producer is
intentionally creating a JWS designed to confuse - in which case the
producer is an attacker.  Do see any other cases in which there is a problem
to address other than when the producer is intentionally emitting "b64":true
but signing as if "b64" was false?

The current security considerations text was intended to do a case analysis
of when there is and isn't a problem, breaking things down by who implements
the extension and who doesn't.  In my analysis, if the recipient rejects a
signature that it doesn't understand, I didn't consider that a security
problem.  Do you agree with that?

While, yes, in retrospect I wish we'd talked about in person too, in
fairness, I did write to the list in my November 2nd note that "I will add
the thoughts above to the Security Considerations section", and that's what
I did, keeping the factual content, but attempting to change the tone from
e-mail conversational to factual.

But I'll try it your way instead, while also keeping the case analysis where
appropriate.  In the meantime, please let me know your thoughts on the two
questions I asked above.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]] 
Sent: Thursday, November 12, 2015 2:24 PM
To: Mike Jones; [email-masked] <mailto:[email-masked]> 
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd
comments

Mike,

Jim

 

From: jose [mailto:[email-masked]] On Behalf Of Manger, James
Sent: Wednesday, November 11, 2015 4:21 PM
To: Mike Jones <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>

  .

 

 

--

James Manger

*

*

                                                                -- Mike

---

From: "Manger, James" <[email-masked]>
Date: Fri, 13 Nov 2015 13:23:09 +1100

> Do see any other cases in which there is a problem to address other than when the producer is intentionally emitting "b64":true but signing as if "b64" was false?

YES.
The producer intentionally creates a proper "b64":false message, but one of the recipients (that the producer might not have known about) hasn't implemented the new spec. That is less likely for a symmetric MAC that will typically only be shared by 2 parties. But it is quite realistic for an asymmetric digital signature that can, by design, be verified by anyone.

> In my analysis, if the recipient rejects a signature that it doesn't understand, I didn't consider that a security problem.  Do you agree with that?

YES, as long as it rejects the signature because the crypto doesn't verify, not just because the content will generally look wrong.

--
James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, 13 November 2015 12:50 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

                                                            -- Mike

Mike,

Jim

--
James Manger

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Nov 2015 02:31:17 +0000

Thanks, James.  I'll cover that case in the rewritten security considerations.  But at least in that case it "fails safe" by rejecting the JWS due to the apparently bad signature.  (That's what the first sentence of paragraph three of the current security considerations section is about; I'll try to make that clearer.)

                                                            -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 6:23 PM
To: Mike Jones; Jim Schaad; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

YES.

--
James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, 13 November 2015 12:50 PM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 2:24 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

Mike,

Jim

--
James Manger

                                                                -- Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Nov 2015 20:03:21 -0500

Mike,

When do you expect to have this ready?  And assuming the shepherd
agrees it's ready for AD review...

Thanks,
Kathleen

On Thu, Nov 12, 2015 at 9:31 PM, Mike Jones <[email-masked]> wrote:
> Thanks, James.  I’ll cover that case in the rewritten security
> considerations.  But at least in that case it “fails safe” by rejecting the
> JWS due to the apparently bad signature.  (That’s what the first sentence of
> paragraph three of the current security considerations section is about;
> I’ll try to make that clearer.)
>
>
>
>                                                             -- Mike
>
>
>
>> Do see any other cases in which there is a problem to address other than
>> when the producer is intentionally emitting “b64”:true but signing as if
>> “b64” was false?
>
>
>
> YES.
>
> The producer intentionally creates a proper "b64":false message, but one of
> the recipients (that the producer might not have known about) hasn’t
> implemented the new spec. That is less likely for a symmetric MAC that will
> typically only be shared by 2 parties. But it is quite realistic for an
> asymmetric digital signature that can, by design, be verified by anyone.
>
>
>
>> In my analysis, if the recipient rejects a signature that it doesn’t
>> understand, I didn’t consider that a security problem.  Do you agree with
>> that?
>
>
>
> YES, as long as it rejects the signature because the crypto doesn’t verify,
> not just because the content will generally look wrong.
>
>
>
> --
>
> James Manger
>
>
>
> It’s not that I think there isn’t ever a problem but I do think that there
> are lots of real cases in which there’s only a problem if the producer is
> intentionally creating a JWS designed to confuse – in which case the
> to address other than when the producer is intentionally emitting “b64”:true
> but signing as if “b64” was false?
>
>
>
> of when there is and isn’t a problem, breaking things down by who implements
> the extension and who doesn’t.  In my analysis, if the recipient rejects a
> signature that it doesn’t understand, I didn’t consider that a security
> While, yes, in retrospect I wish we’d talked about in person too, in
> fairness, I did write to the list in my November 2nd note that “I will add
> the thoughts above to the Security Considerations section”, and that’s what
> But I’ll try it your way instead, while also keeping the case analysis where
> a.      Use the “crit” parameter
>
> 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
>   …
> The signature can, in fact, still verify when "b64":false is ignored —
> handful of bytes (and probably aren’t that confident that everyone
> 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).
>
>
>
> 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
> describing when “crit” should be used.
>
>
>
> ·
> ·
> http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-04.html
>
>
>
>                                                                 -- Mike
>
>
>
> @selfissued.
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Nov 2015 01:22:48 +0000

On my work queue for tomorrow...

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 5:03 PM
To: Mike Jones
Cc: Manger, James; Jim Schaad; [email-masked]
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

Mike,

When do you expect to have this ready?  And assuming the shepherd agrees it's ready for AD review...

Thanks,
Kathleen

On Thu, Nov 12, 2015 at 9:31 PM, Mike Jones <[email-masked]> wrote:
> considerations.  But at least in that case it “fails safe” by 
> rejecting the JWS due to the apparently bad signature.  (That’s what 
> the first sentence of paragraph three of the current security 
> considerations section is about; I’ll try to make that clearer.)
>
>
>
>                                                             -- Mike
>
>
>
>> Do see any other cases in which there is a problem to address other 
>> than when the producer is intentionally emitting “b64”:true but 
>> signing as if “b64” was false?
>
>
>
> YES.
>
> The producer intentionally creates a proper "b64":false message, but 
> one of the recipients (that the producer might not have known about) 
> hasn’t implemented the new spec. That is less likely for a symmetric 
> MAC that will typically only be shared by 2 parties. But it is quite 
> realistic for an asymmetric digital signature that can, by design, be verified by anyone.
>
>
>
>> understand, I didn’t consider that a security problem.  Do you agree 
>> with that?
>
>
>
> YES, as long as it rejects the signature because the crypto doesn’t 
> verify, not just because the content will generally look wrong.
>
>
>
> --
>
> James Manger
>
>
>
> It’s not that I think there isn’t ever a problem but I do think that 
> there are lots of real cases in which there’s only a problem if the 
> producer is intentionally creating a JWS designed to confuse – in 
> which case the producer is an attacker.  Do see any other cases in 
> which there is a problem to address other than when the producer is 
> intentionally emitting “b64”:true but signing as if “b64” was false?
>
>
>
> The current security considerations text was intended to do a case 
> analysis of when there is and isn’t a problem, breaking things down by 
> who implements the extension and who doesn’t.  In my analysis, if the 
> recipient rejects a signature that it doesn’t understand, I didn’t 
> consider that a security problem.  Do you agree with that?
>
>
>
> fairness, I did write to the list in my November 2nd note that “I will 
> add the thoughts above to the Security Considerations section”, and 
> that’s what I did, keeping the factual content, but attempting to 
> change the tone from e-mail conversational to factual.
>
>
>
> But I’ll try it your way instead, while also keeping the case analysis 
> where appropriate.  In the meantime, please let me know your thoughts 
> on the two questions I asked above.
>
>
>
>                                                             -- Mike
>
>
>
> 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.
>
>
>
> 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.
>
> 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!
>
>
>
> 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 
> 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).
>
>
>
> 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
>
>
>
>
>
> 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.
>
>
>
> Mike
> P.S.  This note was also published at http://self-issued.info/?p=1474 
> and as @selfissued.
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Nov 2015 05:01:55 +0000

The security considerations have been reworked in the manner that you suggested, using an example supplied by James.  Thanks to both of you for your diligence.

                                                            -- Mike

From: Mike Jones
Sent: Thursday, November 12, 2015 5:50 PM
To: 'Jim Schaad'; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd comments

                                                            -- Mike

Mike,

Jim

--
James Manger

                                                                -- Mike