On Thu, Jan 25, 2024 at 06:39:06PM -0600, Orie Steele wrote:
> I ended up reading the code behind JSON serialization of JWE with multiple
> recipients here:
>
> https://github.com/panva/jose/blob/main/docs/classes/jwe_general_encrypt.GeneralEncrypt.md
>
> I started by just recovering the same interface with hpke (including
> support for the aad in JWE, which I had destroyed / misused in my previous
> proposal).
>
> I ended with this:
>
> https://github.com/OR13/draft-jose-hpke-test-vectors/blob/main/src/json.ts
>
> You can now use JSON Serialization JWE with recipients that use RSA,
> ECDH-ES+A128KW (etc), and HPKE:
Yes, having to support mixing RSA, ECDH-ES+KW and HPKE is a fairly big
constraint on how multi-recipient JOSE-HPKE has to work (and I think
there is symmetric Key Wrapping as well).
> I repeated the "alg" values in the recipient headers for readability, but
> they are technically not required I think.
No, "alg" in recipient headers is required.
It is just that there is shortcut notation if all recipients have the
same alg.
> The top level header is { enc: A128GCM }
>
> and is input as the aad to the hpke seal and open operations...
That might not be safe.
> I also explored the hkdf binding, but for JWE like this, it does not seem
> to do anything useful, see:
>
> https://github.com/OR13/draft-jose-hpke-test-vectors/blob/main/src/ContentEncryption.ts#L27
>
> I feel pretty embarrassed about the aad proposal from before, because JWE
> supports aad and so hpke jwe needs to preserve some aad interface in json.
JWE supports aad _only_ at top level. Therefore HPKE JWE _only_ needs
to support aad when performing Integrated Encryption.
> I think this means that the aad in seal and open are the only places you
> can reasonably bind the protected header to the content encryption key.
That no existing JWE alg does such thing is already a major problem in
doing that.
> So the main difference between the compact and json serializations boils
> down to this:
Sorry, the way I think about this is:
- Where does each input to Seal come from?
- Where does each output from Seal go to?
With the Open part being left implicit, as it is obvious.
> It seems likely this mixed mode experiment is breaking some rules... when
> decrypting ECDH-ES+A128KW, we don't have a way to know the aead.
Yes, there is no way to know the AEAD when decrypting ECDH-ES+A128KW.
There are three ways for protocol to not fall to CTR/CBC oracle attack:
a) Require top-level authentication (JWE does this).
b) Require binding algorithms in all key encrypt/wrap operations
(Not feasible!).
c) Have KDF between CEK and actual bulk key.
> ... so I think that part is still vulnerable to the cross mode attack...
I think you meant CTR/CBC oracle attack, which does not work in JWE
because of the top-level AEAD requirement.
And the same requirement also makes A128KW illegal top-level algorithm,
blocking possible cross-mode attack.
What makes HPKE potentially vulernable to cross-mode is that it is
allowed for _both_ Key Encryption/Wrapping and top-level.
> to fix that, we would need to bind the shared secret based content
> encryption key, to a single algorithm... I think that implies a new "alg"
> value... something like "ECDH-ES+A128KW+A128GCM" ... you can see where that
> could fit into the existing concatKDF structure here:
> https://github.com/OR13/draft-jose-hpke-test-vectors/blob/main/src/mixed.ts#L70
That doesn't even work.
Fixing CTR/CBC oracle attack against protocol vulnerable to it (JWE is
not) requires inserting KDF step between CEK and actual bulk key.
> Thats probably a separate issue for consideration, not something to hold up
> JOSE HPKE for... possibly for
> https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/
> to address.
Possibly add some requirements that ensure that nobody does anything
really dumb that opens up JWE against CTR/CBC oracle attack (see what
happened with COSE)?
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
