Subject: Re: [jose] High risk vulnerability in RFC 7515

From: Quan Nguyen <[email-masked]>
Date: Wed, 14 Sep 2016 08:34:52 -0700

On Tue, Sep 13, 2016 at 8:43 PM, Quan Nguyen <[email-masked]> wrote:

> Hi,
>
> I'm Quan Nguyen, a Google Information Security Engineer.
>
> RFC 7515, https://tools.ietf.org/html/rfc7515#section-4.1.3  "jwk" (JSON
> Web Key) Header Parameter allows the signature to include the public key
> that corresponds to the key used to digitally sign the JWS. This is a
> really dangerous option [1]
>
> This option allows any attacker to just generate private key /public key
> pair, send the public key together with the signature and and signature
> will be valid. It means that the signature is meaningless and easily
> bypassed. Note that even if it's OPTIONAL, the attacker or MITM can always
> include that field.
>
> I'm aware that you have a section 6 and Appendix D talking about key trust
> decision. However:
>      1.  There is no reason to trust this key
>      2.  There is no way to verify public key's truthfulness to make trust
> decision, unless the receiver already knows the public key in advance (in
> that case, "kid" is enough).
>
> I've seen library making this mistake, but they just followed the RFC, so
> it's hard to convince them to fix the issue. In the end of the day, users
> are vulnerable. Furthermore, I believe this is RFC's vulnerability, not the
> library.
>
> Regards,
>
> -Quan
>
> [1] I'm aware that there may be a rare use-case that needs to send the
> public key, e.g., certificate signing request, but even in that case, the
> user can send the public key, e.g, in opaque field in JWT.
>

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 14 Sep 2016 12:45:34 -0400

OTOH, removing the 'jwk' parameter means that all attributes of keys
need to be duplicated in the header namespace.

I concur that nobody should trust the contents of the jwk parameter
without additional verification. And I would support language of this
type in an errata. But I think the 'jwk' parameter does have real
value.

On Wed, 2016-09-14 at 08:34 -0700, Quan Nguyen wrote:
On Tue, Sep 13, 2016 at 8:43 PM, Quan Nguyen <[email-masked]>
> wrote:
Hi,

RFC 7515, https://tools.ietf.org/html/rfc7515#section-4.1.3  "jwk"
> (JSON Web Key) Header Parameter allows the signature to include the
> public key that corresponds to the key used to digitally sign the
> JWS. This is a really dangerous option [1]

This option allows any attacker to just generate private key /public
> key pair, send the public key together with the signature and and
> signature will be valid. It means that the signature is meaningless
> and easily bypassed. Note that even if it's OPTIONAL, the attacker or
> MITM can always include that field. 

I'm aware that you have a section 6 and Appendix D talking about key
> trust decision. However:
     1.  There is no reason to trust this key
     2.  There is no way to verify public key's truthfulness to make
> trust decision, unless the receiver already knows the public key in
> advance (in that case, "kid" is enough).

I've seen library making this mistake, but they just followed the
> RFC, so it's hard to convince them to fix the issue. In the end of
> the day, users are vulnerable. Furthermore, I believe this is RFC's
> vulnerability, not the library.

Regards,

-Quan

[1] I'm aware that there may be a rare use-case that needs to send
> the public key, e.g., certificate signing request, but even in that
> case, the user can send the public key, e.g, in opaque field in JWT.

_______________________________________________
jose mailing list
[email-masked]
https://www.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 14 Sep 2016 10:47:36 -0700

The jwk parameter is required when doing ephermal-static ECDH as that is the only way to carry the ephemeral key from the sender to the recipient.

One always needs to validate the key no matter how it is obtained so I would have a hard time not saying that this is a library user problem.

Jim

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Nathaniel McCallum
> Sent: Wednesday, September 14, 2016 9:46 AM
> To: Quan Nguyen <[email-masked]>; Michael Jones
> <[email-masked]>; John Bradley <[email-masked]>; 崎村夏彦 <n-
> [email-masked]>; Thai Duong <[email-masked]>; [email-masked]
> Subject: Re: [jose] High risk vulnerability in RFC 7515
> 
> OTOH, removing the 'jwk' parameter means that all attributes of keys need to be
> duplicated in the header namespace.
> 
> I concur that nobody should trust the contents of the jwk parameter without
> additional verification. And I would support language of this type in an errata.
> But I think the 'jwk' parameter does have real value.
> 
> > public key that corresponds to the key used to digitally sign the JWS.
> > This is a really dangerous option [1]
> 
> > RFC, so it's hard to convince them to fix the issue. In the end of the
> > day, users are vulnerable. Furthermore, I believe this is RFC's
> https://www.ietf.org/mailman/listinfo/jose

---

From: Thai Duong <[email-masked]>
Date: Wed, 14 Sep 2016 10:53:56 -0700

On Wed, Sep 14, 2016 at 10:47 AM, Jim Schaad <[email-masked]> wrote:

> The jwk parameter is required when doing ephermal-static ECDH as that is
> the only way to carry the ephemeral key from the sender to the recipient.
>

Quoting https://tools.ietf.org/html/rfc7515#section-4.1.3

"The "jwk" (JSON Web Key) Header Parameter is the public key that
   corresponds to the key used to digitally sign the JWS.  This key is
   represented as a JSON Web Key [JWK].  Use of this Header Parameter is
   OPTIONAL."

At any rate there's no reason that the ECDH ephemeral key shouldn't be part
of the ciphertext.

> One always needs to validate the key no matter how it is obtained so I
> would have a hard time not saying that this is a library user problem.
>

Blaming users is easy. Helping them not make mistakes is right.

> without

---

From: Thai Duong <[email-masked]>
Date: Wed, 14 Sep 2016 10:33:04 -0700

On Wed, Sep 14, 2016 at 9:51 AM, Thai Duong <[email-masked]> wrote:

> (cross-posting from another thread)
>
> One thing to keep in mind is that the public key tag contains a raw public
> key, not a certificate.
>
> How can the receivers verify the public key? They'll have to compute a
> fingerprint and compare with some existing key. But if they already have
> the key, a keyID should be used. Do you agree?
>
> In other words the public key is useless. It's also dangerous because
> people might forget to validate it.
>

If crypto standards give users enough ropes, they will hang themselves.
Look at the vulnerabilities that were caused by allowing users to specify
the algorithm [1].

Allowing users to use in-band raw public keys would also lead to broken
implementations.

The algorithm and public key field should be removed. The only way to
specify the crypto algorithm is the keyID which would map to {crypto
scheme, keying material} that the senders and receivers had agreed.

Example:

- A and B agrees to use HMAC-SHA256-TRUNCATED. They share a key K, and
agree that keyID = 0 maps to {HMAC-SHA256-TRUNCATED, K}.

- Later on they switch to RSA-2048-SHA256. A shares with B the public key
PK, and both sides agree that keyID = 1 maps to {RSA-2048-SHA256, PK}. If a
X509 certificate is used, keyID can be bound to {RSA-2048-SHA256, cert
extracted from the message}

- If B needs to accept messages from multiple senders, they can assign the
keyID to each sender. As long as the keyID is unique among pairs of
{sender, receiver}, the design should work flawlessly, and there's very
little chance for implementations to make mistakes.

[1] https://auth0.com/blog/critical-vulnerabilities-in-
json-web-token-libraries/

>
> On Wed, Sep 14, 2016, 9:45 AM Nathaniel McCallum <[email-masked]>
> wrote:
>

---

From: Thai Duong <[email-masked]>
Date: Wed, 14 Sep 2016 16:51:48 +0000

---

From: Quan Nguyen <[email-masked]>
Date: Wed, 14 Sep 2016 19:30:21 -0700

On Wed, Sep 14, 2016 at 10:53 AM, Thai Duong <[email-masked]> wrote:

> At any rate there's no reason that the ECDH ephemeral key shouldn't be
> part of the ciphertext.
>

Re ECDH issue: As we're here, it's worth to differentiate between
encryption (e.g. ECDH, RSA encryption) and signature.

"jwk" is also allowed in encryption
https://tools.ietf.org/html/rfc7516#section-4.1.5. I was *not* concerned
about it. It's not ideal but it has limited security impact because at
best, the attacker can force the receiver to use one of the keys in
*receiver*'s key set.

On the other hand, embedded public key in signature has a significant
security impact.