Inline On Fri, Jan 26, 2024, 5:18 AM Ilari Liusvaara <[email protected]> wrote:
> 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). > > > Probably we will need mixed mode tests with existing libraries then, and those libraries will need to ignore HPKE but still decrypt. > > 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. > We will need to ensure the value is equally protected then, in HPKE it's not being used at all. In ECDH it is bound it is applied to the concatkdf, and I assume it is also protected with other bits that I have not implemented here yet. > 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. > > > > This is the existing behavior when RSA and ECDH are both used. If we change this, I expect we won't be able to support HPKE alongside them in multiple recipients. @Filip Skokan <[email protected]> perhaps you have a comment here? > > > 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. > > > > I don't agree, no JWE KEMs exist, should we never add support for KEMs? As soon as we add KEMs we have to address context bindings for the serialization. IIRC, COSE does the same exact thing... Protected Headers need to be protected somehow. > > 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. > > > When you open with AAD you know seal happened with the same value. This proves to the decryptor that the aead they are about to use, that could be cross mode... Is correct. With one layer HPKE this doesn't matter because there is only the hole suite, which handles this internally. With 2 layer, we could omit this binding and the properties of ECDH-ES could be preserved, including no way to trust aead without top layer integrity protection. It seems wrong to seal an encryption key, for a specific algorithm, and not tell the recipient that, in the sealing process. > > 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. > > > Right, as you said it comes from the top level integrity protection, which JOSE and COSE HPKE currently don't have. > 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. > > > I assume you mean the content encryption key... You want that given a shared secret derived content encryption key, that process should prevent you from changing the aead, without causing a new secret key... As the proposal for CMS does. Of the options you propose, I think the only one that will work without breaking existing implementations and while adding hpke is option number 1. That seems like the next thing to prove out. > > ... 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 vulnerable to cross-mode is that it is > allowed for _both_ Key Encryption/Wrapping and top-level. > > > I don't think so, because the HPKE cipher suite does the binding, and when you have no second layer ahead, there is nothing that can be changed. HPKE cannot protect the second layer aead algorithm binding, unless seal is used to do so. > > 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. > > > That is where the cek key comes from, so that is where you would fix it. And since concatKdf mixes a partially specified algorithm instead of a fully specified one that includes the aead, it does seem to me that you could fix this, by keeping the existing kdf and using a fully specified algorithm. > > 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)? > > > Perhaps we can start a new thread for this, and track issues for guidance. > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
