Re: [jose] [COSE] HPKE PartyU / PartyV

[Ilari Liusvaara <[e-mail]>]

On Thu, Feb 29, 2024 at 11:04:57AM -0600, Orie Steele wrote:
> I think we actually agree here.
> 
> The remaining point is just what to do in HPKE.
>
> 1. New header parameters, mandatory processing rules, mix
> content encryption algorithm into the KDF (via HPKE INFO).

HPKE does not allow using both INFO and AAD for one message (I do not
know why), and INFO has a short length limit (because it is used in
ways that pretty much require buffering).

So only AAD can be used.


> 2. New Enc_structure, (fix disconnected layers vulnerability), protect
> "Enc_structure" with AAD (via HPKE AAD).

impl MultiRecipientEncrypt
{
	pub fn new(alg: EncryptionAlgorithm, rng: &mut TemporaryRandomStream) ->
		Result<MultiRecipientEncrypt, String>
	{
		//...
	}
	pub fn get_key(&self) -> &[u8] { &self.key }
	pub fn add_recipient(&mut self, recipient: &[CBOR])
	{
		//...
	}
	pub fn finish<M:MessageSink>(self, ad: &dyn EncryptAdditionalInfo, msg: &[u8], to: M) ->
		Result<<<M as MessageSink>::Buffer as MessageBuffer>::Residual, String>
	{
		//...
	}
}

Any current other-type recipient (which is pretty much anything that is
not a Direct Encryption or Direct Key Agreement) can be supported via
that interface.

But it can not support anything that mixes layers. Hence mixing layers
is a breaking change.

And COSE design clearly intends for the layers to be kept separate.


> What JWE allows, is based on the algorithms it relies on, and their
> processing rules are algorithm specific, for example:
> 
> https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.1.2

All those processing rules operate on the JOSE header. Which means no
distinction between protected and unprotected.

This allows interface analogous to the above to work in JOSE.


> So both 1 and 2 can also work for JOSE, except that there is no
> "Enc_structure", there is just the normative language regarding:
> 
> "What to set for HPKE AAD in seal and open" and "What to set for HPKE
> INFO"...
> 
> If we are not going to create COSE_KDF_CONTEXT, then suggest we will also
> not create ConcatKDF context in JOSE.
> 
> So HPKE INFO, will be the same in both JOSE HPKE and COSE HPKE.
> 
> The guidance that JOSE provides regarding using the protected header bytes
> as aad, seems reasonable.
> 
> https://datatracker.ietf.org/doc/html/rfc7516#appendix-A.4.5
> 
> """
> Let the Additional Authenticated Data encryption parameter be
> ASCII(BASE64URL(UTF8(JWE Protected Header)))
> """
> 
> When you apply this guidance to HPKE Direct / Integrated Encryption, there
> is only the top level protected header to consider since there is only a
> single recipient.

Yes, as long as the HPKE enc is not in protected headers, that is
completely reasonable thing to do.


> When you apply this guidance to HPKE Key Encryption, in JOSE, you are
> "mixing layers", but that's ok to do, because there is no way to understand
> any of the HPKE algorithms in the context of JOSE without reading the RFC
> that defines that behavior... which we are hopefully progressing through
> these debates : )

No, it is not ok. 

The "attack" you are trying to "fix" can never work against JWE. 

And JWE clearly intends an API analogous to the above COSE example to
work. Again, it is broken by mixing layers. There is even a precedent on
how AEAD-capable algorithm behaves: It does not mix layers.


> The logic for COSE is the same, regarding proposals 1 and 2.

With unfortunate difference that RFC 8152 (nor does RFC 9052) did not
explicitly state a critical security requirement. And then some folks
went ahead and added a thing that makes it insecure.

(Bonus points for making a thing I can't figure out how to use
correctly in any useful way...)


> I like your comment regarding the fully specified algorithms draft...
> considering the encryption use case for fully specified algorithms:
> 
> https://www.rfc-editor.org/rfc/rfc7520#section-5.6.3
> 
> {
>      "alg": "dir",
>      "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a",
>      "enc": "A128GCM"
> }
> 
> {
>      "alg": "dir",
>      "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a",
>      "enc": "HPKE-Base-P256-SHA256-AES128GCM"
> }
> 
> I would consider both of these cases "fully specified".

>From draft-ietf-jose-fully-specified-algorithms, section 5.

"So for instance, for JOSE, alg values and enc values MUST each be
fully specified, and their behaviors MUST NOT depend upon one another."

This means that legal enc and legal alg values can be freely combined.


> One is fully specified by listing a single AEAD algorithm.
> 
> The other is fully specified by listing an HPKE SUITE, that bundles KEM,
> KDF and AEAD together.

The problem is that once you have "enc", it will do its thing. Any
interference from "alg" is prohibited.

And once you have "alg", it will do its thing, any interference from
"enc" is prohibited.

 
> In the context of COSE, we don't have "enc", but we do have fully specified
> algorithms for COSE HPKE.

COSE has layers. And it is clear that those are not allowed to interfere
with one another.




-Ilari