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

[Mike Ounsworth <[e-mail]>]

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]> 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/statement
s/handling-ballot-positions/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_
giHweh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxS-023Peg$
<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statement
s/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-lamp
s-cms-kemri/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC
5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxSZn3FNhw$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamp
s-cms-kemri/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC
5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxSZn3FNhw$> 
 
 
 
----------------------------------------------------------------------
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-l
amps-cms-cek-hkdf-sha256/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giH
weh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQa702bBQ$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-housley-l
amps-cms-cek-hkdf-sha256/__;!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giH
weh7ipifWddvC5DjKdkJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQa702bBQ$> 
 
Or the algorithm integrity protection comments in:
 
https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9459.html*sect
ion-8__;Iw!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKd
kJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQbrRdCPw$
<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9459.html*sect
ion-8__;Iw!!FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKd
kJIAXTJgrkpABvkWWRp3eqGs7CAhvmxQbrRdCPw$> 
 
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_giHweh7ipifWddvC5DjKdkJIAXTJgrkpA
BvkWWRp3eqGs7CAhvmxT8KnKO4w$
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!
FJ-Y8qCqXTj2!Y3B2eNStiUUjdo-t3e_Ujl1ugvxIR_giHweh7ipifWddvC5DjKdkJIAXTJgrkpA
BvkWWRp3eqGs7CAhvmxT8KnKO4w$>