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

["lgl island-resort.com" <[e-mail]>]

So here’s a possible new Enc_structure Orie suggested. I’m calling it Rec_structure. It is just for COSE_Recipients.


Rec_structure = [
    context :  “Enc_Recipient” / “Rec_Recipient",
    protected : empty_or_serialized_map,
    next_alg : int/tstr
]

- protected is for the protected headers from the COSE_Recpient
- No external_aad since COSE_Recipient doesn’t have that
- Pass this as the aad parameter to Seal() as Ilari suggests
- next_alg is the COSE algorithm ID from the COSE layer below and is mandatory

The COSE layer crossing here is pretty much the same as for COSE_KDF_Context.AlgorithmID for a COSE Recipient with alg ID -25. That is, there is already this layer-crossing in RFC 9053.

I've intentionally chose only the algorithm ID, not all the protected headers from layer 0.  This is because of implementation complexity and memory use. My COSE implementation can handle arbitrarily large blocks of header parameters (plus arbitrarily large external_aad) without allocating memory through use of incremental hashing. I don’t want to have multiple incremental hashes in flight at once, one for each recipient, nor do I want to put a cap on the size of header parameters or use malloc. Passing only the algorithm ID across layers is simpler and cleaner.

I’ve implemented  COSE_KDF_Context.AlgorithmID. This will be almost identical.

Also, no COSE_KDF_Context.SuppPubInfo.keyDataLength because COSE alg IDs are all for a specific key length.

Last, I think this would work when we fix COSE alg ID -29.

LL



On Feb 29, 2024, at 3:30 PM, Orie Steele <[e-mail]> wrote:

Inline:

On Thu, Feb 29, 2024 at 2:03 PM Ilari Liusvaara <[e-mail]<mailto:[e-mail]>> wrote:
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])
        {
                //...

Here is where your recipient code checks the algorithm.
Constructs the Enc_Structure (either fixing, or not fixing the AES-CBC issue).
Encrypts the content encryption key, using Enc_structure as AAD.
And sets the encrypted_key of the recipient structure.

IMO, it's a mistake to encrypt a symmetric key if you are not sure what it will be used for...
especially if the attacker can change its use from AES-GCM to AES-CBC.

You can call refusing to encrypt a key without knowing the algorithm it will be used with a layer violation.
... I call it a security oriented design improvement.

        }
        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.

I don't get why it cannot, if it's because the protected header is not known yet... You could refactor your code.

Why do all the "recipient work", only to figure out that AES-CBC is requested and your library has decided to not implement it...
or is prohibited from implementing it... as is the case for JOSE.


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


Then its design needs to account for attacks that exploit the layer separation.

You can claim layer purity as a justification for handing out decryption keys for private messages.

But I don't have to agree with you : )


> 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.

I've implemented both HPKE modes in JOSE and COSE.

It's working fine in protected headers for me...

I don't think it needs to be in protected headers, but in compact JWE...
that's the only header, so that's where it goes... ( encrypted JWT ... digital identity / credential use cases ).

This also lines up with traditional compact JWE encryption...

  const key1 = await jose.generateKeyPair('ECDH-ES+A128KW', { crv: 'P-256', extractable: true })
  const jwe = await new jose.CompactEncrypt(
    new TextEncoder().encode('It’s a dangerous business, Frodo, going out your door.'),
  )
    .setProtectedHeader({ alg: 'ECDH-ES+A128KW', enc: 'A128GCM' })
    .encrypt(key1.publicKey)
  const { plaintext, protectedHeader } = await jose.compactDecrypt(jwe, key1.privateKey);
  expect(protectedHeader.alg).toBe('ECDH-ES+A128KW')
  expect(protectedHeader.enc).toBe('A128GCM')
  expect(protectedHeader.epk.kty).toBe('EC')
  expect(protectedHeader.epk.crv).toBe('P-256')
  // protected header also protects the epk.
  expect(new TextDecoder().decode(plaintext)).toBe('It’s a dangerous business, Frodo, going out your door.')




> 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.

I'm not trying to fix it for JWE, because those algorithms are prohibited in JWE:

https://www.iana.org/assignments/jose/jose.xhtml

I am trying to make HPKE AAD take protected headers, because that's how they are protected in JOSE.

I'm also trying to place "encapsulated keys" in protected and unprotected headers, because that's where "epk" goes in JOSE.


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.

counterpoint, see the JOSE examples above:

expect(protectedHeader.alg).toBe('ECDH-ES+A128KW')
expect(protectedHeader.enc).toBe('A128GCM')

If you set A128GCM AAD to be the protected header, your AEAD is providing integrity for your key agreement and key wrapping algorithm identifier.

We know this is not required, because we also have JOSE protected headers that look like this:
{
  "enc": "A128GCM",
  "epk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "ticr_5a7x5Y4kWPRKIEjMV1ufG_AUW4Ud9Aapmx1uOY",
    "y": "eWboqDQfzcDOaGnNRXansvIG9QgeYrjhs3dh60vQA0M"
  }
}



> 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...)

: )

And this is why we have 2 lists included on this thread.

We don't want to end up making JOSE vulnerable by following COSE advice,
or make COSE vulnerable by following JOSE advice... There are important security differences.

We also don't want encapsulated keys treated differently in ways that make security analysis difficult.

Part of the reason why is that we already have security analysis for "epk" in both JOSE and COSE,
and that's conceptually what DHKems are outputting via "enc".



> 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.

I don't follow... is your point that:

{
     "alg": "Ed25519",
     "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a",
     "enc": "A128GCM"
}

Make no sense?...

I agree but that does not invalid that both "A128GCM" and "HPKE-Base-P256-SHA256-AES128GCM" are fully specified.



> 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.

I think that's an argument in favor of :

{
     "alg": "dir",
     "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a",
     "enc": "HPKE-Base-P256-SHA256-AES128GCM"
}

For direct / integrated encryption in JOSE?


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

What do I do with "dir", if I can't look at "enc" ?



> 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.


I'd say it's clear they interfered with each other in ways that produced vulnerabilities.

That's ok, everyone makes mistakes.

https://datatracker.ietf.org/doc/html/rfc9459 (and it seems the IETF agrees).

Let's return to the solution:

HPKE AAD = CBOR ( [ "Encrypt1", CBOR ( RecipientProtectedHeader ),  CBOR ( ProtectedHeader ), external_aad ])

If you think Encrypt1 should never have external aad, you don't need a new structure, you can use Encrypt0 with the layer0 protected header AS external AAD.

HPKE AAD = CBOR ( [ "Encrypt0", CBOR ( RecipientProtectedHeader ),  CBOR ( ProtectedHeader ) ])

Logically you are encrypting a content encryption key to a single recipient... so this seems... not that terrible.

This won't stop an attacker from ignoring HPKE recipients and toggling A128GCM to A128CBC...

But it will prevent HPKE recipients from accidentally handing out an AES-GCM key 16 bytes at a time for content that might not be exclusively encrypted to them...

I might not be able to convince my friend to use HPKE, but I don't have to help an attacker decrypt our shared private content.




-Ilari

_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose


--

ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose