Re: [lamps] [EXTERNAL] Murray Kucherawy's No Objection on draft-ietf-lamps-cms-kemri-08: (with COMMENT)

[Orie Steele <[e-mail]>]

Hey Mike,

I'm not a CMS expert, I'll refine the possible attack, and if my refinement
still doesn't convince anyone it's possible, I'm happy to have displayed my
ignorance so publicly : )

Let's imagine a scenario where you have content encrypted with AES-GCM, and
the CEK is encrypted to multiple recipients.

The attacker knows one of the recipients supports AES-CBC, and changes the
content encryption algorithm to AES-CBC, hoping the recipient will leak
leaks part of the AES-GCM key per, the attack described in
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-cek-hkdf-sha256/

When you have direct encryption, the KDF can bind the context of the
content encryption algorithm.

When you have wrap encryption, that is still possible, but you need to know
more than just "this is a wrapped key", you would need to know "this is a
wrapped key for AES-GCM".

There are other possible mitigations depending on the constructions used,
for KEMs "info" seems to be where that binding would take place.

This is possibly an issue in COSE with -29,
 https://www.iana.org/assignments/cose/cose.xhtml#key-type
<https://www.iana.org/assignments/cose/cose.xhtml#key-type>, because -29
only commits to "A128KW" in the KDF... it does not commit to "and then use
that key with AES-GCM", hence:
https://www.rfc-editor.org/rfc/rfc9459.html#section-8

We want an attacker changing the content encryption algorithm to fail
closed, I am unsure if that property is achieved in the document, based on
my inexperience with CMS.

OS






On Thu, Mar 7, 2024 at 9:12 AM Mike Ounsworth <[e-mail]>
wrote:

> Hi @Orie Steele <[e-mail]>
>
>
>
> I am intrigued by your comments, but I don’t fully understand them.
>
>
>
> My understanding:
>
> CMS has some data payload to encrypt. The sender will generate a random
> CEK or CAEK. It will encrypt the payload with AES-CBC or AES-GCM. So far
> this is all basic CMS RFC5652 behaviour. The KEMRI draft adds the ability
> to protect the CEK or CAEK for one or more recipients’ KEM certificate –
> more than one recipient is for things like email with more than one person
> in the TO: field, so you encrypt the CEK / CAEK multiple times rather than
> encrypting the entire payload multiple times.
>
>
>
> So with that understanding, I don’t think I follow your comments.
>
>
>
> The payload will be encrypted once, with either AES-CBC or AES-GCM, with a
> unique key per payload. I don’t see where cross-mode attacks are introduced.
>
>
>
> The CMS headers will specify both the KeyEncryptionAlgorithmIdentifier
> (inside KEMRecipientInfo), and ContentEncryptionAlgorithmIdentifier (inside
> EncryptedContentInfo). If those specify that, for example, the payload was
> encrypted with ContentEncryptionAlgorithmIdentifier = AES-CBC, and the CEK
> was encrypted with KeyEncryptionAlgorithmIdentifier = AES-GCM. I don’t see
> how you get an attack here.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Spasm <[e-mail]> *On Behalf Of *Murray Kucherawy
> via Datatracker
> *Sent:* Thursday, March 7, 2024 1:17 AM
> *To:* The IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* [EXTERNAL] [lamps] Murray Kucherawy's No Objection on
> draft-ietf-lamps-cms-kemri-08: (with COMMENT)
>
>
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lamps-cms-kemri-08: No Objection When responding, please keep
> the subject line intact and reply to all email addresses included in the To
> and CC lines. (Feel free to
>
> Murray Kucherawy has entered the following ballot position for
>
> draft-ietf-lamps-cms-kemri-08: No Objection
>
>
>
> When responding, please keep the subject line intact and reply to all
>
> email addresses included in the To and CC lines. (Feel free to cut this
>
> introductory paragraph, however.)
>
>
>
>
>
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxS-023Peg$ <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxS-023Peg$>
>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
>
>
>
> The document, along with other ballot positions, can be found here:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxSZn3FNhw$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxSZn3FNhw$>
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> ===
>
>
>
> >From Orie Steele, incoming ART Area Director:
>
>
>
> Thanks to Sean Turner for the ARTART review, and the PR.
>
>
>
> The security considerations mentions both AES-GCM and AES-CBC.
>
>
>
> Is there a need to comment on binding the CEK or CAEK to a specific symmetric
>
> encryption algorithm, similar to:
>
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-housley-lamps-cms-cek-hkdf-sha256/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQa702bBQ$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-housley-lamps-cms-cek-hkdf-sha256/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQa702bBQ$>
>
>
>
> Or the algorithm integrity protection comments in:
>
>
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9459.html*section-8__;Iw!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQbrRdCPw$ <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9459.html*section-8__;Iw!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQbrRdCPw$>
>
>
>
> I am concerned about how cross mode attacks are or are not mitigated by this
>
> document, but I lack the CMS experience to be able to compare the security
>
> properties to COSE.
>
>
>
> """
>
> In this environment, security depends on three things. First, the KEM algorithm
>
> must be secure against adaptive chosen ciphertext attacks. Second, the
>
> key-encryption algorithm must provide confidentiality and integrity protection.
>
> Third, the choices of the KDF and the key-encryption algorithm need to provide
>
> the same level of security as the KEM algorithm. """
>
>
>
> It seems like there is possibly a missing criteria that assures that the same
>
> content encryption algorithm is used on both sides of the KEM interface, after
>
> the CEK or CAEK is decrypted?
>
>
>
>
>
>
>
> _______________________________________________
>
> Spasm mailing list
>
> [e-mail]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxT8KnKO4w$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxT8KnKO4w$>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>