Re: [jose] High risk vulnerability in RFC 7515

On Wed, Sep 14, 2016 at 10:53 AM, Thai Duong <thaidn@google.com> wrote:

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

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