Subject: [Unbearable] JWS

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jul 2015 12:43:03 +0200

Though I'm ashamed to admit that I didn't think of this earlier, I
have to ask...

Why aren't we using JWS?

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 24 Jul 2015 11:08:39 -0700

> Why aren't we using JWS?

This comes to mind:

https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

What about interop with non-JWS/JWT bearer token formats?

(Or perhaps I misunderstand what you mean by "using JWS"?)

-- 
Tony Arcieri

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Jul 2015 20:19:19 +0200

Using JWS to sign the TLS unique?   

It would seem that web-crypto would support it and Defiantly OpenID Connect and OAuth 2 doing Pop tokens. 

The compact JWS serialization is designed for headers. 

There is probably some obvious reason, but I don't know it as one of the JWS authors. 

John B. 

Sent from my iPhone

> On Jul 24, 2015, at 12:43 PM, Martin Thomson <[email-masked]> wrote:
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jul 2015 11:39:17 -0700

> There is probably some obvious reason, but I don't know it as one of the
JWS authors.

That was exactly my thinking.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Jul 2015 11:46:03 -0700

On 7/24/15 11:08 AM, Tony Arcieri wrote:
> On Fri, Jul 24, 2015 at 3:43 AM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Why aren't we using JWS?
>
>
> This comes to mind:
>

I would point to the fact that we (now) have libraries that have been
vetted as a reason to use JWS, not the other way around.

(or maybe that's what you meant)

-Jim

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Jul 2015 20:46:18 +0200

In the meeting today I was thinking that we have a JWA registry for sig algorithms that could be used.  However I didn’t want to add to the confusion.

John B.
> On Jul 24, 2015, at 8:39 PM, Martin Thomson <[email-masked]> wrote:
> 
> 
> On Jul 24, 2015 8:19 PM, "John Bradley" <[email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Mike Jones <[email-masked]>
Date: Fri, 24 Jul 2015 18:50:37 +0000

There's lots of interoperable, tested JWS libraries now for essentially every widely-used development platform.  See http://openid.net/developers/libraries/#jwt and http://jwt.io/, plus the blog post https://auth0.com/blog/2015/07/21/jwt-json-webtoken-logo/.

                                                            -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Jim Fenton
Sent: Friday, July 24, 2015 11:46 AM
To: Tony Arcieri; Martin Thomson
Cc: [email-masked]
Subject: Re: [Unbearable] JWS

On 7/24/15 11:08 AM, Tony Arcieri wrote:
On Fri, Jul 24, 2015 at 3:43 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Why aren't we using JWS?

This comes to mind:

https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fauth0.com%2fblog%2f2015%2f03%2f31%2fcritical-vulnerabilities-in-json-web-token-libraries%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c603f029c57314343ca5a08d2945825a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fPpfcHR%2f4S8VQAYL1B8FpD1zCRVcuPaYhvsGDoiWSQY%3d>

I would point to the fact that we (now) have libraries that have been vetted as a reason to use JWS, not the other way around.

-Jim

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 24 Jul 2015 11:54:18 -0700

> (or maybe that's what you meant)

If finding a single vuln meant that a library is "vetted", OpenSSL would be
an impenetrable fortress by now.

This particular vulnerability speaks to what I think is a design flaw that
adds sharp edges to the format, namely that an attacker can choose
algorithms as part of a malleable portion of the message which the verifier
needs to interpret in order to verify the messages.

It's not an intractable problem, but it is one that leads to implementation
difficulties, and is one of the reasons I've avoided JWT and instead used
bearer token formats where these sort of problems are impossible by design.

I would like to leverage tokbind, but it saddens me that to do so I might
have to add this attack surface back.

-- 
Tony Arcieri

---

From: Mike Jones <[email-masked]>
Date: Fri, 24 Jul 2015 18:58:24 +0000

When using the JWS Compact Serialization http://tools.ietf.org/html/rfc7515#section-3.1, which is what Token Binding would use, attackers can’t choose algorithms because the algorithm identifier is included in the integrity-protected information.

                                                            -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Tony Arcieri
Sent: Friday, July 24, 2015 11:54 AM
To: Jim Fenton
Cc: [email-masked]; Martin Thomson
Subject: Re: [Unbearable] JWS

On Fri, Jul 24, 2015 at 11:46 AM, Jim Fenton <[email-masked]<mailto:[email-masked]>> wrote:
I would point to the fact that we (now) have libraries that have been vetted as a reason to use JWS, not the other way around.

If finding a single vuln meant that a library is "vetted", OpenSSL would be an impenetrable fortress by now.

This particular vulnerability speaks to what I think is a design flaw that adds sharp edges to the format, namely that an attacker can choose algorithms as part of a malleable portion of the message which the verifier needs to interpret in order to verify the messages.

It's not an intractable problem, but it is one that leads to implementation difficulties, and is one of the reasons I've avoided JWT and instead used bearer token formats where these sort of problems are impossible by design.

I would like to leverage tokbind, but it saddens me that to do so I might have to add this attack surface back.

--
Tony Arcieri

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Jul 2015 21:09:40 +0200

The JWS would be self signed over the tls unique and public key.   I don’t know if there is an attack posable based on changing the alg of the signature over the tls unique.

This is separate to the question of how the server might bind a cookie to that public key.    I expect that JWS will also be a popular choice for that.   

The advantage would mostly be that the signing algs might align better.

John B.

> On Jul 24, 2015, at 8:58 PM, Mike Jones <[email-masked]> wrote:
> 
> When using the JWS Compact Serialization http://tools.ietf.org/html/rfc7515#section-3.1 <http://tools.ietf.org/html/rfc7515#section-3.1>, which is what Token Binding would use, attackers can’t choose algorithms because the algorithm identifier is included in the integrity-protected information.
>  
>                                                             -- Mike
>  
> On Fri, Jul 24, 2015 at 11:46 AM, Jim Fenton <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 24 Jul 2015 19:30:52 -0700

On Fri, Jul 24, 2015 at 12:09 PM, John Bradley <[email-masked]> wrote:

> The JWS would be self signed over the tls unique and public key.   I don’t
> know if there is an attack posable based on changing the alg of the
> signature over the tls unique.
>

To flip your statement around, if there were any sort of attack against
this sort of self-signed signature, lots of things would be possible.

In general, my reaction is you all have a particularly scary attitude for a
WG that's supposedly attempting to develop secure software.

Going back to this:

> vetted as a reason to use JWS, not the other way around.

If people are finding vulnerabilities, that's not a good sign. That's a bad
sign. That's a sign that you should be worried.

Every single reaction I've received from everyone who has posted a response
to me in this thread has only elevated my concerns.

Things are not proceeding in a direction I would generally deem
trustworthy, and that worries me. There are lots of signals of problems,
and the general reaction I'm getting from this WG is to downplay every
single security-related concern I've broached. I find this particularly
concerning.

-- 
Tony Arcieri

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Jul 2015 20:43:58 -0700

On 7/24/15 7:30 PM, Tony Arcieri wrote:
>     I would point to the fact that we (now) have libraries that have
>     been vetted as a reason to use JWS, not the other way around.
>
>
> If people are finding vulnerabilities, that's not a good sign. That's
> a bad sign. That's a sign that you should be worried.

I agree that a library that has had a bug found and fixed does not mean
that it has been vetted. I expressed this wrong.

But having a library that has had at least some degree of use and
debugging is an advantage over doing something different and writing new
libraries from scratch. That is, unless the new alternative is less
likely to result in implementation errors. I believe there was an
assertion earlier that the alternative being proposed is somehow more
likely to be implemented correctly. If so, I don't understand the basis
for that assertion, and I'd like to.

-Jim

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 24 Jul 2015 21:15:16 -0700

On Fri, Jul 24, 2015 at 8:43 PM, Jim Fenton <[email-masked]> wrote:

> libraries from scratch.

I don't think JWS/JWT are the only game in town. There are alternatives to
consider which don't involve "writing new libraries from scratch"

-- 
Tony Arcieri

---

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

What attacks are you worried about Tony?  As I’d written earlier, an attacker can’t change the algorithm for signed/MACed content, since the algorithm identifier is integrity protected and the signature will be rejected if not produced by the algorithm protected in the header.

Also, I’ll observe that verifying that the algorithm used is currently acceptable to the application is a standard part of any cryptographic workflow.  Just like you wouldn’t accept an MD5 MAC because it’s not in your acceptable algorithms list, you wouldn’t accept “none” for the same reason.  This necessary algorithm hygiene step is explicitly required by JWS, with this language:
   Finally, note that it is an application decision which algorithms may
   be used in a given context.  Even if a JWS can be successfully
   validated, unless the algorithm(s) used in the JWS are acceptable to
   the application, it SHOULD consider the JWS to be invalid.

                                                            Best wishes,
                                                            -- Mike

From: Tony Arcieri [mailto:[email-masked]]
Sent: Friday, July 24, 2015 9:15 PM
To: Jim Fenton
Cc: John Bradley; Mike Jones; [email-masked]; Martin Thomson
Subject: Re: [Unbearable] JWS

On Fri, Jul 24, 2015 at 8:43 PM, Jim Fenton <[email-masked]<mailto:[email-masked]>> wrote:
I agree that a library that has had a bug found and fixed does not mean that it has been vetted. I expressed this wrong.

But having a library that has had at least some degree of use and debugging is an advantage over doing something different and writing new libraries from scratch.

I don't think JWS/JWT are the only game in town. There are alternatives to consider which don't involve "writing new libraries from scratch"

--
Tony Arcieri

---

From: Phil Hunt <[email-masked]>
Date: Sat, 25 Jul 2015 08:18:57 +0200

+1. 

Phil

> On Jul 25, 2015, at 06:30, Mike Jones <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Sat, 25 Jul 2015 10:22:12 +0200

It is true that JWS/JWT are not the only game in town.   In point of fact the Token Binding specs don’t use JWS/JWT at this point.

This started form a question, asking why we don’t reuse that signature/envelope format vs something custom.

That is a reasonable thing to ask and people to provide opinions on, however I don’t think it is a indication that we are close to making a change.

The blog post you point to has information on two implementation flaws (it is argued that they are caused by a design flaw allowing the implementation flaws) 
1: that a receiver blindly uses the alg specified in the assertion, without respect to it’s relationship with the sender.   This is a algorithm down grade attack and is not unique to JWS/JWE.
2: That an attacker knowing the public key and key_id for a sender can craft a assertion that uses a HMAC algorithm with that public key.   Any signature verification that allows keys to be used with the wrong algorithm is problematic.

If these attacks can compromise token binding then they need to be addressed in whatever signature method we use.
At the F2F we did ask for an expansion of the security considerations.

I would like to understand the attacks on this level of the protocol.

We have a alg negotiation phase,   
Can an attacker who has a token bound token and knows the public key negotiate a algorithm downgrade that would let them sign without the original private key?
After a alg for a key is established at the server is that maintained across sessions or is a new TLS session able to negotiate a different alg for the same key?

I think that is the more general question.

I suspect the correct answer is that the alg for a UA is established before the self signed token is sent, and the server MUST not allow a different alg to be negotiated for that key, otherwise it would be treated as a new key.   That would apply equally to any envelope we use.

I hope we can capture some of this in the new security considerations, as it might be something that a implementer could get wrong.

Regards
John B.

> On Jul 25, 2015, at 6:15 AM, Tony Arcieri <[email-masked]> wrote:
> 
> On Fri, Jul 24, 2015 at 8:43 PM, Jim Fenton <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 25 Jul 2015 10:17:21 -0700

On Fri, Jul 24, 2015 at 9:30 PM, Mike Jones <[email-masked]>
wrote:

>  What attacks are you worried about Tony?
>

Ones that arise from logic/implementation bugs in buggy verifiers/libraries

> As I’d written earlier, an attacker can’t change the algorithm for
> signed/MACed content, since the algorithm identifier is integrity protected
> and the signature will be rejected if not produced by the algorithm
> protected in the header.
>

Except, as has actually happened in more than one case, you can trick buggy
implementations into interpreting RSA public keys as symmetric MAC keys.
Oops. This speaks to why stuffing both MACs and digital signatures into a
single standard and letting them be used interchangeably was probably a bad
idea.

>  Also, I’ll observe that verifying that the algorithm used is currently
> acceptable to the application is a standard part of any cryptographic
> workflow.
>

"Cipher agility" is growingly reviled among many experts I know in the
cryptography community, and it's totally unnecessary for this use case.
Instead of including algorithm names in the token, you can just include an
opaque key ID/handle, and the verifier should understand the mapping of
KIDs to keys and associated verification algorithms. It's not information
that should be supplied by the token. It not only wastes space, but
encourages implementers to make the mistakes that lead to these sort of
attacks.

-- 
Tony Arcieri

---

From: Phil Hunt <[email-masked]>
Date: Sat, 25 Jul 2015 16:59:47 -0700

Give us a reason beyond FUD that we can discuss please. 

Phil

> On Jul 25, 2015, at 10:17, Tony Arcieri <[email-masked]> wrote:
> 
>> On Fri, Jul 24, 2015 at 9:30 PM, Mike Jones <[email-masked]> wrote:
>> As I’d written earlier, an attacker can’t change the algorithm for signed/MACed content, since the algorithm identifier is integrity protected and the signature will be rejected if not produced by the algorithm protected in the header.
>> 
> 
> Except, as has actually happened in more than one case, you can trick buggy implementations into interpreting RSA public keys as symmetric MAC keys. Oops. This speaks to why stuffing both MACs and digital signatures into a single standard and letting them be used interchangeably was probably a bad idea.
>  
>> Also, I’ll observe that verifying that the algorithm used is currently acceptable to the application is a standard part of any cryptographic workflow. 
>> 
> 
> 
> "Cipher agility" is growingly reviled among many experts I know in the cryptography community, and it's totally unnecessary for this use case. Instead of including algorithm names in the token, you can just include an opaque key ID/handle, and the verifier should understand the mapping of KIDs to keys and associated verification algorithms. It's not information that should be supplied by the token. It not only wastes space, but encourages implementers to make the mistakes that lead to these sort of attacks.
> 
> -- 
> Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 26 Jul 2015 11:17:34 -0700

JWS just seems like a lot more than you need. By using it, you run the risk
of hitting one of these logic bugs, and exposing yourself to bugclasses
that otherwise wouldn't exist.

Otherwise it does seem like the evolving least common denominator for this
sort of thing.

On Sat, Jul 25, 2015 at 4:59 PM, Phil Hunt <[email-masked]> wrote:

> Except, as has actually happened in more than one case, you can trick
> buggy implementations into interpreting RSA public keys as symmetric MAC
> keys. Oops. This speaks to why stuffing both MACs and digital signatures
> into a single standard and letting them be used interchangeably was
> probably a bad idea.
>
>

-- 
Tony Arcieri

---

From: Phil Hunt <[email-masked]>
Date: Sun, 26 Jul 2015 11:59:38 -0700

Thanks Tony. I thinks that is a better point. 

I think the use of JWS here is not introducing any new risks that we aren't already exposed to. 

We already use JWS in tokens and http payloads. 

Phil

> On Jul 26, 2015, at 11:17, Tony Arcieri <[email-masked]> wrote:
> 
> JWS just seems like a lot more than you need. By using it, you run the risk of hitting one of these logic bugs, and exposing yourself to bugclasses that otherwise wouldn't exist.
> 
> Otherwise it does seem like the evolving least common denominator for this sort of thing.
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 26 Jul 2015 22:37:12 +0300

> that we aren't already exposed to. 

JWS can represent inconsistent algorithms, the present format can not.

And there have been multiple very serious JWS library security
bugs due to inconsistent algorithms.

-Ilari

---

From: Leif Johansson <[email-masked]>
Date: Sun, 26 Jul 2015 22:46:38 +0200

> bugs due to inconsistent algorithms.

Unless these bugs stem from issues with the specification I'm going to
put on my chairs hat and call "rathole" on this thread.

If anyone wants tokbind to use JWS (and I can see both pros and cons)
then please suggest text - perhaps via a pull-request - so the WG can
evaluate a specific suggestion.

	Cheers Leif