On Fri, Jan 26, 2024 at 08:19:39AM -0600, Orie Steele wrote:
> Inline
>
> On Fri, Jan 26, 2024, 5:18 AM Ilari Liusvaara <[email protected]>
> wrote:
> >
> > 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.
Yup.
> > > 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 not protected at all for Key Encryption/Wrapping.
> > > 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?
Neither RSA nor ECDH protect any headers.
> > > 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.
KEMs are Key Agreement, and there already is ECDH-ES.
There are only two required differences to ECDH-ES:
- KEM ciphertext is put in new header as base64url-encoded stirng
instead of putting ephemeral public key value in "epk".
- Z is KEM shared secret instead of ECDH-ES key agreement output.
> IIRC, COSE does the same exact thing... Protected Headers need to be
> protected somehow.
In COSE, protected headers are always per-layer, and only allowed if
the algorithm in that layer is actually capable of protecting those.
E.g., note that protected headers are not allowed with AE.
> > > 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.
JWE has to assume Key Encryption/Wrapping is incapable of protecting
that, as it allows using AES-KW and RSA-OEAP.
> > > 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.
And as I said, that is not a problem with JOSE, but it is a problem with
COSE.
And in COSE it is not problem just with HPKE, it is problem with every
indirect key managment mode. Most of those are not even capable of
protecting any headers!
> > 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.
The only thing needed is to ensure that adding HPKE does not break it.
It can be easily shown (since touching those parts destroys arbitration)
that anything that could break it is something inherently single-
recipient.
> > > 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.
Key Encryption mode breaks that.
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
