Re: [jose] High risk vulnerability in RFC 7515

On Wed, Sep 14, 2016 at 10:47 AM, Jim Schaad <ietf@augustcellars.com> 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.

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