On Wed, Sep 14, 2016 at 10:53 AM, Thai Duong <[email protected]> wrote:
> > > On Wed, Sep 14, 2016 at 10:47 AM, Jim Schaad <[email protected]> > 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. > 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. > > >> 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. > >> Jim >> >> >> > -----Original Message----- >> > From: jose [mailto:[email protected]] On Behalf Of Nathaniel >> McCallum >> > Sent: Wednesday, September 14, 2016 9:46 AM >> > To: Quan Nguyen <[email protected]>; Michael Jones >> > <[email protected]>; John Bradley <[email protected]>; 崎村夏彦 <n- >> > [email protected]>; Thai Duong <[email protected]>; [email protected] >> > 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 <[email protected]> >> > > 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 >> > [email protected] >> > https://www. >> > >> > _______________________________________________ >> > jose mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/jose >> >> >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
