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

[Mike Ounsworth <[e-mail]>]

Hi Orie,

 

Ok, that’s clearer. I’m following now.

 

You’re referring to this line in draft-ietf-lamps-cms-cek-hkdf-sha256:

 

“””

Providing the object identifier as an inout to the key derivation function is sufficient to mitigate the attack described in [RS2023], but this mitigation includes both the object identifier and the parameters to protect against some yet-to-be-discovered attack that only manipulates the parameters.

“””

 

draft-kemri does require that this structure is input to the KDF:



CMSORIforKEMOtherInfo ::= SEQUENCE {

        wrap KeyEncryptionAlgorithmIdentifier,

        kekLength INTEGER (1..65535),

        ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

 

therefore the KeyEncryptionAlgorithmIdentifier is bound.

 

 

I would have to do a deeper dive, but I think your attack gets at the existing CMS (RFC5652) behaviour of EnvelopedData to retrieve the CEK / CAEK from the RecipientInfo and use it, without performing a KDF in between. So *I think* your concern is outside the scope of KEMRecipientInfo, and would apply equally to KeyTransRecipientInfo (RSA), KeyAgreeRecipientInfo (DH / ECDH), etc. Also, in practice there is often the mitigation that EnvelopedData (ie content encrypted for the recipient’s public key) is inside a SignedData (ie content signed by the sender’s public key), which prevent manipulation of AlgorithmIDs.

 

 

 

 

By the way  <mailto:[e-mail]> @Russ Housley: typo in the Security Considerations: “Providing the object identifier as an *inout* to the key derivation”

 

---

Mike Ounsworth

 

From: Orie Steele <[e-mail]> 
Sent: Thursday, March 7, 2024 9:24 AM
To: Mike Ounsworth <[e-mail]>
Cc: Murray Kucherawy <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [EXTERNAL] [lamps] Murray Kucherawy's No Objection on draft-ietf-lamps-cms-kemri-08: (with COMMENT)

 

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 



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/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-cms-cek-hkdf-sha256/__;!!FJ-Y8qCqXTj2!bknDRONSifkqrpK7aSwhF_Qlqx0Uue19D0cYkIhEOZ3Tg_la8N3aa_JNgA6fVlh247-I1YVjg1JptTk8wEoHsBzAoak$> 

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://urldefense.com/v3/__https:/www.iana.org/assignments/cose/cose.xhtml*key-type__;Iw!!FJ-Y8qCqXTj2!bknDRONSifkqrpK7aSwhF_Qlqx0Uue19D0cYkIhEOZ3Tg_la8N3aa_JNgA6fVlh247-I1YVjg1JptTk8wEoHD4ww1TA$>  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 <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9459.html*section-8__;Iw!!FJ-Y8qCqXTj2!bknDRONSifkqrpK7aSwhF_Qlqx0Uue19D0cYkIhEOZ3Tg_la8N3aa_JNgA6fVlh247-I1YVjg1JptTk8wEoHtR4YN7Y$> 

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] <mailto:[e-mail]> > wrote:

Hi  <mailto:[e-mail]> @Orie Steele

 

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] <mailto:[e-mail]> > On Behalf Of Murray Kucherawy via Datatracker
Sent: Thursday, March 7, 2024 1:17 AM
To: The IESG <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[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] <mailto:[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://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!bknDRONSifkqrpK7aSwhF_Qlqx0Uue19D0cYkIhEOZ3Tg_la8N3aa_JNgA6fVlh247-I1YVjg1JptTk8wEoHvq1SOLw$> 

 <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!bknDRONSifkqrpK7aSwhF_Qlqx0Uue19D0cYkIhEOZ3Tg_la8N3aa_JNgA6fVlh247-I1YVjg1JptTk8wEoH-xG9YvE$>