Re: [lamps] [EXTERNAL] Re: AD review of draft-ietf-lamps-cms-kemri-05

[Falko Strenzke <[e-mail]>]

Hi John,

I don't see how the ukm field can prevent cross-mode attacks. In a cross 
mode attack, the attacker takes an original AEAD encrypted message, 
applies suitable transformations to it, and then lets the victim decrypt 
it as a CBC message. Since the victim's decrypting client doesn't 
interpret the contents of the ukm field (which the attacker leaves 
unchanged), the derived AES key for the CBC decryption will be the same 
as for the (originally intended) AEAD decryption, and the attacker can 
thus exploit cross-mode relations among the different encryption modes 
(CTR/CBC in this case – CTR is used in both AES-CCM and AES-GCM defined 
for CMS [1] ). See [2] for the general idea but note that these are just 
examples for such attacks and not necessarily report the security 
implications of cross-mode attacks completely.

To defend against such attacks, an input to the key derivation is needed 
that is dependent on the contentEncryptionAlgorithm that is actually 
used in the decryption of that message. Only then it is ensured that 
when the attacker changes the contentEncryptionAlgorithm, a different 
AES key will be used during decryption than that for the original 
message, thus making cross-mode attacks impossible.

- Falko

[1] https://datatracker.ietf.org/doc/html/rfc5084

[2] 
https://www.researchgate.net/publication/45787175_Related-Mode_Attacks_on_CTR_Encryption_Mode

Am 24.10.23 um 23:20 schrieb John Gray:
>
> Hi Falko,
>
> I think we already have accommodation for this in the draft via the 
> optional ukm field:
>
> CMSORIforKEMOtherInfo ::= SEQUENCE {
>
>            wrap KeyEncryptionAlgorithmIdentifier,
>
>            kekLength INTEGER (1..65535),
>
> *           ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }*
>
> ukm is optional user keying material.  When the ukm value is
>
>       provided, it is used as part of the info structure described in
>
>       Section 5 to provide a context input to the key-derivation
>
>       function. *For example, the ukm value could include a nonce,*
>
> *      application-specific context information, or an identifier for the*
>
> *      originator.*A KEM algorithm may place requirements on the ukm
>
>       value.  Implementations that do not support the ukm field SHOULD
>
>       gracefully discontinue processing when the ukm field is present.
>
>       Note that this requirement expands the original purpose of the ukm
>
>       described in Section 10.2.6 of [RFC5652]; it is not limited to
>
>       being used with key agreement algorithms.
>
> If you wanted to include the contentEncryptionAlgorithm as context 
> information to be used for key derivation, you can already do that 
> with this field.  I think it should achieve what you are looking for 
> (key separation) as it is used as context input to the KDF.
>
> Cheers,
>
> John Gray
>
> *From:* Spasm <[e-mail]> *On Behalf Of * Falko Strenzke
> *Sent:* Tuesday, October 24, 2023 8:31 AM
> *To:* Roman Danyliw <[e-mail]>; [e-mail]
> *Cc:* Johannes Roth <[e-mail]>
> *Subject:* [EXTERNAL] Re: [lamps] AD review of 
> draft-ietf-lamps-cms-kemri-05
>
> We are aware that the document draft-ietf-lamps-cms-kemri 
> <https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/> is 
> already in the AD review and thus far progressed in its process of 
> finalisation. We have a good reason to propose a modification to this 
> document still at this late stage. Both the suggested change and the 
> reason for it are explained in the following.
>
>
>       Proposed change
>
> We propose to include the algorithm identifier of the symmetric scheme 
> used for the payload encryption, i.e., the contentEncryptionAlgorithm, 
> in CMSORIforKEMOtherInfo.
>
>
>       Reason for the proposed change
>
> The reason is, besides it generally being best practice to include 
> such contextual information into the key deriviation, that there is 
> the threat of AEAD-to-CBC cross-mode / downgrade attacks against 
> state-of-the-art CMS. The KEM-RI draft has the opportunity to remove 
> this potential weakness at least for KEMs and thus we strongly suggest 
> to make this change. Including the contentEncryptionAlgorithm in the 
> key derivation ensures that one arrives at different content 
> encryption keys if the contentEncryptionAlgorithm is changed (for 
> instance) from AEAD to CBC.
>
> Please note that also the OpenPGP crypto-refresh 
> <https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/> 
> incorporates a key derivation – that deviates in its parameters from 
> what we propose here and is only used in the case of AEAD – that 
> ensures key separation for the newly introduced AEAD and the legacy 
> CFB encrypted data packets.
>
> - Falko Strenzke and Johannes Roth
>
> Am 11.10.23 um 21:58 schrieb Roman Danyliw:
>
>     Hi!
>
>       
>
>     I performed an AD review of draft-ietf-lamps-cms-kemri-05.  Thanks for this very important update to CMS.  This document is in good shape.  As the below are minor, I'll advance this to IETF LC and ask that this feedback be resolved concurrently.
>
>       
>
>     ** Section 2.  Editorial. Should the distribution of the recipient’s public key be made explicit?
>
>     OLD
>
>         In advance, each recipient uses KeyGen() to create a key pair, and
>
>         then obtains a certificate [RFC5280] that includes the public key.
>
>       
>
>     NEW
>
>       
>
>     In advance, each recipient uses the KEM KeyGen() function to create a key pair, and then may obtains a certificate [RFC5280] that includes this newly generated public key.  This public key or associated certificate is them made available.
>
>       
>
>     ** Section 2.  Editorial.  Recommendation for several sections.  When a KEM function, KeyGen()/Encapsulate()/Decapsulate() is mentioned, referred to is as a “KEM <insert function name>”.  For example, s/Encapsulate() function/KEM Encapsulate() function/
>
>       
>
>     ** Section 3.
>
>            The
>
>            RecipientIdentifier provides two alternatives for specifying the
>
>            recipient's certificate [RFC5280]
>
>       
>
>     Isn’t the correct reference for the two mechanisms in RecipientIdentifier (i.e., issuerAndSerialNumber and subjectKeyIdentifier) provided by RFC5652?
>
>       
>
>     ** Section 3.  Editorial
>
>          The issuerAndSerialNumber alternative identifies the
>
>            recipient's certificate by the issuer's distinguished name and the
>
>            certificate serial number; the subjectKeyIdentifier identifies the
>
>            recipient's certificate by a key identifier.
>
>       
>
>     Is there a missing “or” between these two options?  Both don’t need to be present in the RecipientIdentifier structure.
>
>       
>
>     ** Section 3.  Process question.
>
>            Note that this requirement expands the original purpose of the ukm
>
>            described in Section 10.2.6 of [RFC5652]; it is not limited to
>
>            being used with key agreement algorithms.
>
>       
>
>     Does this imply that this RFC should formally “update” RFC5652?
>
>       
>
>     ** Section 6.1.  Since SMIME-CAPS is being used in the formal definition of the KEY-ALGORITHM class, RFC 5912 needs to be a normative reference.  RFC5912 is informational, but it already in the DOWNREF registry.
>
>       
>
>     ** Section 6.1. As an aside, what is the SMIME link to KEMs?
>
>       
>
>     ** Section 7.
>
>         The choice of the KDF SHOULD be made based on the security level
>
>         provided by the KEM.  The KDF SHOULD at least have the security level
>
>         of the KEM.
>
>       
>
>     What is the nuance being conveyed between these two sentences?  What additional considerations exist beyond what is spelled out in the second sentence?  This construct is repeated in the next paragraphs for key-encryption algorithms too.
>
>       
>
>     ** Section 7.  Typo. s/used to by the/used by the/
>
>       
>
>     Regards,
>
>     Roman
>
>     _______________________________________________
>
>     Spasm mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/spasm
>
> -- 
>
> *MTG AG*
> Dr. Falko Strenzke
> Executive System Architect
>
> Phone: [phone]
> E-Mail: [e-mail]
> Web: mtg.de <https://www.mtg.de>
>
> ------------------------------------------------------------------------
>
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
>
> This email may contain confidential and/or privileged information. If 
> you are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this email. 
> Unauthorised copying or distribution of this email is not permitted.
>
> Data protection information: Privacy policy 
> <https://www.mtg.de/en/privacy-policy>
>
> /Any email and files/attachments transmitted with it are intended 
> solely for the use of the individual or entity to whom they are 
> addressed. If this message has been sent to you in error, you must not 
> copy, distribute or disclose of the information it contains. _Please 
> notify Entrust immediately and delete the message from your system._/ 
-- 

*MTG AG*
Dr. Falko Strenzke
Executive System Architect

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>


------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>