Re: [jose] HPKE Compact JWE Demo

[Orie Steele <[e-mail]>]

On Thu, Feb 15, 2024 at 7:14 AM Ilari Liusvaara <[e-mail]>
wrote:

> On Sun, Feb 11, 2024 at 06:22:39PM -0600, Orie Steele wrote:
> >
> > On Sun, Feb 11, 2024 at 2:40 PM Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > > On Sun, Feb 11, 2024 at 12:13:22PM -0600, Orie Steele wrote:
> > > >
> > > > On Sun, Feb 11, 2024, 10:17 AM Ilari Liusvaara <
> [e-mail]
> > > >
> > > > With HPKE using Key Encryption, those steps are the same, and the
> > > algorithm
> > > > is present in the recipient header.
> > >
> > > If all recipients have the same alg, it can also be in global headers
> > > (protected or unprotected).
> > >
> >
> > That's an unfortunate "or" but I assume we must preserve it?
> >
> > I've added 2 placeholder tests for these cases, if we must preserve this
> > behavior, we will at least provide examples.
>
> JWE section 5.2. step 4:
>
> ------------------------------------------------------------------------
> Otherwise, when using the JWE JSON Serialization, let the JOSE Header be
> the union of the members of the JWE Protected Header, the JWE Shared
> Unprotected Header and the corresponding JWE Per-Recipient Unprotected
> Header, all of which must be completely valid JSON objects.
> ------------------------------------------------------------------------
>
> JWE section 7.2.1:
>
> ------------------------------------------------------------------------
> Some Header Parameters, including the "alg" parameter, can be shared
> among all recipient computations.  Header Parameters in the JWE
> Protected Header and JWE Shared Unprotected Header values are shared
> among all recipients.
> ------------------------------------------------------------------------
>
>
Yes, we got similar comments off list about how we treat the
requirements for header params.

The suggestion was to only comment on parts of HPKE that need to be in
protected headers.

We'll work the text that direction


>
> > > > Key Encryption is already defined by JWE (RFC 7516).
> > > > >
> > > >
> > > > And is our use of the term consistent?
> > >
> > > Yes. Except I think there are some instances of KAwKW should be KE.
> > >
> >
> > I'm not sure how to address this, but it's possible it is better to wait
> > for a new version on the datatracker to see if we cleared it up by then.
>
> Searching for "Key Agreement" or "Key Wrapping" in editor's copy:
>
>
> Section "Overview":
> ------------------------------------------------------------------------
> JSON Web Algorithms (JWA) {{Section 4.6 of RFC7518}} defines two ways to
> use public key cryptography with JWE:
>
> - Direct Key Agreement

- Key Agreement with Key Wrapping
> ------------------------------------------------------------------------
> Two problems with that:
>
> 1) Those modes are defined by JWE, not JWA.
>

How to use them is defined here:

https://datatracker.ietf.org/doc/html/rfc7516#section-5.1


> 2) There is third mode: Key Encryption.
>

Yes, its defined here:
https://datatracker.ietf.org/doc/html/rfc7516#section-2

"""
   Key Encryption
      A Key Management Mode in which the CEK value is encrypted to the
      intended recipient using an asymmetric encryption algorithm.
"""


> Section "Overview":
> ------------------------------------------------------------------------
> This specification describes two modes of use for HPKE in JWE:
>
>   *  Integrated Encryption mode, where HPKE is used with a single
>      recipient. This setup is conceptually similar to Direct Key
>      Agreement, and is only compatible with JWE Compact Serialization.
>
>   *  Key Encryption mode, where HPKE is used with multiple recipients.
>      This setup is conceptually similar to Key Agreement with Key
>      Wrapping, and is only compatible with General JWE JSON
>      Serialization, and Flattened JWE JSON Serialization.
> ------------------------------------------------------------------------
> That looks to need a rewrite.
>
> Maybe something like:
>
> * Integrated Encryption mode, where HPKE is used to directly encrypt
>   the (possibly compressed) message.
>



>
> * Key Encryption mode, where HPKE is used as a recipient to encrypt
>   the CEK. Multiple recipients require General JWE JSON Serialization.
>
>
>
Take a look at https://github.com/tireddy2/JOSE_HPKE/pull/20/files


> Section "Overview":
> ------------------------------------------------------------------------
> We provide the following table for additional clarity:
>
> | Name                   | Recipients | Serializations | Content
> Encryption Key | Similar to
> |---
> | Integrated Encryption  | 1          | Compact        | Derived from
> HPKE      | Direct Key Agreement
> | Key Encryption         | Many       | JSON           | Encrypted by
> HPKE      | Key Agreement with Key Wrapping
> {: #serialization-mode-table align="left" title="JOSE HPKE Serializations
> and Modes"}
> ------------------------------------------------------------------------
> I do not think that table clarifies things.
>
> Maybe something like:
>
> | Name                  | Recipients | HPKE Encrypts
> |---
> | Integrated Encryption | 1          | Message
> | Key Encryption        | >=1        | Content Encryption Key
>

https://github.com/tireddy2/JOSE_HPKE/pull/20/files#r1491040261


>
> Section "Security Considerations":
> ------------------------------------------------------------------------
> HPKE relies on a source of randomness to be available on the device. In
> Key Agreement with Key Wrapping mode, CEK has to be randomly generated
> and it MUST be ensured that the guidelines in {{RFC8937}} for random
> number generations are followed.
> ------------------------------------------------------------------------
> "Key Agreement with Key Wrapping" -> "Key Encryption"
>
>
> And I randomly spotted:
>
> "- Content Encryption Key (CEK), is defined in {{RFC7517}}."
>
> RFC7517 is JWK, I presume that should be RFC7516 (JWE)?
>

Yep, it should be a reference to
https://datatracker.ietf.org/doc/html/rfc7516#section-2


>
>
> > > > > The draft does not register header parameter for that, but a key
> type.
> > > > >
> > > >
> > > > That's correct, because there exists a header parameter that carries
> keys
> > > > called epk.
> > >
> > > However, encapsulated keys are not themselves keys.
> > >
> >
> > In the case of DHKems, they are literally public keys (uncompressed)
> > starting with the 04 prefix, then x component, then y component.
> >
> > Sure HPKE says it's "opaque bytes", are we building a key format that
> > is only for HPKE?
> > In that case kty: EK, ek: enc is as much a key as any other opaque
> > symmetric key.
>
> Modern KEMs have ciphertexts that are byte strings.
>
> E.g., ML-KEM.
>
> And even if those are not, it is easy to map to byte string. JWS and
> COSE_sign both require signatures to be byte strings. ECDSA signatures
> are not (it is integer pair), so those just get mapped to byte strings.
>
>
> > > And what the heck should implementation do with JWK of such type? Key
> > > types are primarily for JWK, it is just that those get reused for
> > > ECDH-ES (which does indeed have ephemeral keys).
> > >
> >
> > JWK supports many different keys, the only required parameter is "kty".
>
> JWK might "support" it but, AFAICT, it makes no sense.
>

This is just "where you add new header params".

This would be a good topic for IETF 119, and we have the deck from the COSE
WG where we asked the same question.

The rough answer from COSE seemed to be to not fracture the "encapsulated
key"... but we did not show a proposal for COSE Key to the group at that
time.


>
>
> > > And then I noticed that all ciphersuites have base mode, but there are
> > > "psk_id" and "auth_kid" parameters, that only make sense for non-base
> > > modes. Do those headers implicitly modify mode, or are there just no
> > > ciphersuites available?
> > >
> >
> > Yep, we added those in advance of actually being able to use them with
> any
> > suites.
> >
> > We will need suites for them.
>
> Lots of suites, yay. :-)
>

Choosing not to distinguish them seems worse, but yeah... : )


>
>
> > > (There is an attack if auth/auth_psk modes are used for key
> encryption).
> > >
> >
> > What is the attack?
>
> The message is not actually authenticated because anyone that gets the
> CEK (e.g, because they are a recipient) can not just to read the
> message, but to also undetectably modify it.
>
> Not sure what is the "official" term for that sort of attack.
>
> And looks like even Integrated Encryption is vulnerable to a weaker
> version: Anyone that manages to somehow obtain the HPKE internal
> symmetric key can undetectably modify the message. That might be
> rather undesirable in some situations...
>
>
>
In order to do this, the attacker needs control of the decryption process
running on the endpoint right? That seems pretty catastrophic.

It sounds like you are wanting something where the JWE ciphertext structure
is bound into the decapsulation operation, so that any changes to the JWE
structure causes the content encryption key to fail to be unwrapped.

I suspect that trying to tackle this would make backwards compatibility
with JWE difficult... I'm not suggesting this, but one way to accomplish
it, might be to canonicalize and hash the JWE and then include a special
header parameter for recipients to use if they want to be protected from
these kinds of changes.


>
>
> -Ilari
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>