On Sun, Feb 11, 2024 at 06:22:39PM -0600, Orie Steele wrote:
>
> On Sun, Feb 11, 2024 at 2:40 PM Ilari Liusvaara <[email protected]>
> wrote:
>
> > On Sun, Feb 11, 2024 at 12:13:22PM -0600, Orie Steele wrote:
> > >
> > > On Sun, Feb 11, 2024, 10:17 AM Ilari Liusvaara <[email protected]
> > >
> > > 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.
------------------------------------------------------------------------
> > > 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.
2) There is third mode: Key Encryption.
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.
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
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)?
> > > > 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.
> > 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. :-)
> > (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...
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
