[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Les Hazlewood <[e-mail]>]

Apologies, I misread the compact form in the version 01 draft - it does
indeed included the cek ciphertext, but not the iv or aad tag.  But my
comments/questions about mandatory `alg` and `enc` values are still valid I
believe.

On Mon, Jul 8, 2024 at 9:58 AM Les Hazlewood <[e-mail]> wrote:

> Thanks Orie,
>
> As a long-time implementer and maintainer of a widely used JOSE library,
> I'm have some concerns that I hope could be addressed.  Admittedly, most of
> my questions are relevant to single recipient and compact (JWT) forms.
>
> I don't think for JWE there should ever be an omitted `alg` header
> parameter: its omission and/or 'none' value can and has caused security
> problems in the past for parsers and this feels like opening a can of worms
> again.  Further, it adds cyclomatic complexity (conditionals) for
> validation assertions that, I hope, shouldn't ever be necessary.
> Non-absent deterministic values are so much nicer and reduce potential
> problems.
>
> The way `alg` has always worked (conceptually at least) IMO from a library
> implementor point of view is it means "the algorithm used to obtain the
> AEAD content encryption key and its potentially associated ciphertext".
>  `enc` is "the algorithm used to AEAD encrypt the payload".  That is,
> (pseudocode):
>
> enc_alg = enc_registry.find( header['enc'] )
> key_alg = alg_registry.find( header['alg'] )
> kek = keystore.find( header['kid'] )
> cek, cek_ciphertext = key_alg((kek, encAlg, header)
>
> For JWE:
>
> - No `alg` inherently means "there isn't a way to obtain an cek/cdk".
> - No `enc` means "the payload is not encrypted", so both must always be
> present for JWE.
> - No JWE ciphertext token in the compact JWE string means 'there is no
> encrypted key ciphertext', when clearly there is (encapsulation).
>
> I could be missing something (and happy to be educated accordingly), but I
> would really like to see the HPKE work maintain these existing constructs -
> changing them to introduce additional complexity is not an intuitive, nor
> safe, idea IMO.
>
> Respectfully,
>
> Les Hazlewood
> JJWT author/maintainer
>
> On Sun, Jul 7, 2024 at 3:17 PM Orie Steele <[e-mail]>
> wrote:
>
>> Hello,
>>
>> I have done my best to apply all the feedback gathered from the adoption
>> call, and I want to draw your attention to the latest draft, and its
>> primary remaining obstacles for discussion at ietf 120.
>>
>> In my haste, I may have destroyed something essential. Apologies to my
>> co-authors, feel free to roast me at the mic line.
>>
>> Be advised the github repo for the working group adopted draft is
>> currently here, PRs are welcome:
>>
>> https://github.com/OR13/draft-ietf-jose-hpke-encrypt
>>
>> As you can see from the document history -01 addresses several points of
>> feedback, and uses the terminology and guidance regarding algorithm names
>> provided by Ilari and others.
>>
>> Major changes in this version:
>>
>> - JWK is no longer used for encapsulated keys, but "encrypted_key" JWE
>> member and "ek" header parameter are.
>> - HPKE mode (base / auth / psk / psk_auth) is no longer included in
>> algorithm registrations.
>> - HPKE Setup info and aad are addressed in a single location for both
>> integrated and key encryption with hpke.
>> - "dir" approach has been replaced with "enc": <some registered aead>.
>> - "jwe aad" examples have been added.
>> - "psk_id" and "auth_kid" examples have been added.
>>
>> I've implemented version -01, and the examples are produced from my
>> prototype.
>>
>> Risk areas, and things which we would like to resolve ASAP.
>>
>> ### Fully specified HPKE algorithms
>>
>> It would be nice to have confidence that the algorithm names will not
>> change.
>>
>> For example where we currently see:
>>
>> ```
>> "alg": "HPKE-P256-SHA256-A128GCM",
>> "enc": "A128GCM",
>> ```
>>
>> We might see:
>>
>> ```
>> "alg": "HPKE-P256-SHA256",
>> "enc": "A128GCM",
>> ```
>>
>> Or whatever the working group decides counts as a "fully specified HPKE
>> algorithm".
>>
>> ```
>> "alg": "HPKE-P256-SHA256+A128KW", ?
>> ```
>>
>> ### HPKE AAD vs JWE AAD
>>
>> I think the current approach is better than computing some custom KDF
>> info from apu / apv... But is setting the following as HPKE AAD enough?
>>
>> hpke-info = empty
>> hpke-aad = encode-protected-header . aad (when JWE aad is available)
>>
>> Where encoded protected header is either the protected header for
>> hpke jwe integrated encryption, or the protected header used in content
>> encryption, for which the content encryption key is being encrypted?
>>
>> ### Lossy conversions
>>
>> It's possible to express things in JSON Serialization that can't be
>> expressed in Compact serialization.
>> I tried to make this explicit, but we could decide to simply forbid
>> conversions from JSON to Compact that lose information, or that would move
>> things around "ek" to "encrypted_key".
>>
>>
>> Thanks for all the feedback during the adoption call.
>>
>> Regards,
>>
>> OS
>>
>> --
>>
>>
>> ORIE STEELE
>> Chief Technology Officer
>> www.transmute.industries
>>
>> <https://transmute.industries>
>> _______________________________________________
>> jose mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>