Re: [jose] High risk vulnerability in RFC 7515

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:jose-bounces@ietf.org] On Behalf Of Nathaniel McCallum
> Sent: Wednesday, September 14, 2016 9:46 AM
> To: Quan Nguyen <quannguyen@google.com>; Michael Jones
> <mbj@microsoft.com>; John Bradley <ve7jtb@ve7jtb.com>; 崎村夏彦 <n-
> sakimura@nri.co.jp>; Thai Duong <thaidn@google.com>; jose@ietf.org
> 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.
> 
> On Wed, 2016-09-14 at 08:34 -0700, Quan Nguyen wrote:
> >
> >
> On Tue, Sep 13, 2016 at 8:43 PM, Quan Nguyen <quannguyen@google.com>
> > 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.
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose