Data threshold for message protection

[HBrock]

Do we want to add a generic security consideration on how much data shall be protected using one key.

[HBrock]

Meeting 11.05.23 John offerd to look into it.

[johngray-dev]

In CMS KEM draft-ietf-lamps-cms-kemri we have the following note:

To be appropriate for use with this specification, the KEM algorithm MUST explicitly be designed to be secure when the public key is used many times. For example, a KEM algorithm with a single-use public key is not appropriate because the public key is expected to be carried in a long-lived certificate [RFC5280] and used over and over. Thus, KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are appropriate. A common design pattern for obtaining IND-CCA2 security with public key reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant of the FO transform [HHK].

We could probably reuse some or most of this text because it is possible a CMP server or client could use a KEM key for a long period of time for message protection. We could recommend the server rotate its protection keys periodically to mitigate this issue (I think that would be a best practice). Therefore a KEM with a limited use key would not be acceptable, and an IND-CCA2 KEM should be recommended.

[HBrock]

Thank you for this proposal. I extended the text a little to "Recurring Usage of KEM Keys for Message Protection

A shared secret key (ssk) used for MAC-based message protection MUST only be used for the PKI management operation indicated by the transactionID in the KemOtherInfo.

It is assumed that the overall size of data of all CMP messages in a PKI management operation protected by one shared secret key is small and not introducing additional security risks.

To be appropriate for use with this specification, the KEM algorithm MUST explicitly be designed to be secure when the public key is used many times. For example, a KEM algorithm with a single-use public key is not appropriate because the public key is expected to be carried in a long-lived certificate [RFC5280] and used over and over. Thus, KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are appropriate. A common design pattern for obtaining IND-CCA2 security with public key reuse is to apply the Fujisaki-Okamoto (FO) transform [Fujisaki] or a variant of the FO transform [Hofheinz]."

@johngray-dev what do you think?

[DDvO]

To me this sounds good. I'd suggest Just a re-phrase of the 2nd paragraph to:

It is assumed that the overall data size of the CMP messages in a PKI management operation protected by a single ssk is small enough not to introduce extra security risks.

[HBrock]

Thank you for the proposal.

[ounsworth]

This looks good to me too.

I suggest adding a summary sentence to the end of the IND-CCA2 paragraph:

Therefore, given a long-term public key using an IND-CCA2 secure KEM algorithm, there is no limit to the number of CMP messages that can be encrypted under it.

[johngray-dev]

Thanks for the suggested edits. They look good to me. Therefore, to summarize all the changes:

"Recurring Usage of KEM Keys for Message Protection

A shared secret key (ssk) used for MAC-based message protection MUST only be used for the PKI management operation indicated by the transactionID in the KemOtherInfo.

It is assumed that the overall data size of the CMP messages in a PKI management operation protected by a single shared secret key is small enough not to introduce extra security risks.

To be appropriate for use with this specification, the KEM algorithm MUST explicitly be designed to be secure when the public key is used many times. For example, a KEM algorithm with a single-use public key is not appropriate because the public key is expected to be carried in a long-lived certificate [RFC5280] and used over and over. Thus, KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are appropriate. A common design pattern for obtaining IND-CCA2 security with public key reuse is to apply the Fujisaki-Okamoto (FO) transform [Fujisaki] or a variant of the FO transform [Hofheinz].

Therefore, given a long-term public key using an IND-CCA2 secure KEM algorithm, there is no limit to the number of CMP messages that can be encrypted under it."

[HBrock]

A shared secret key (ssk) used for MAC-based message protection MUST only be used for the PKI management operation indicated by the transactionID in the KemOtherInfo.

It is right, that one ssk shall only be used for one PKI management operation. But I struggle with 'indicated by ...', specifically as the transactionID is optional. May be we can rephrase.

Each PKI management operation MUST use a fresh KEM cyphertext (ct) and therefore a frech shared secret key (ssk) for MAC-based message protection.

[DDvO]

Yeah, unfortunately we cannot fully rely on the presence of the transactionID.

I suggest focusing on ssk only:

The shared secret key (ssk) used for MAC-based message protection must be fresh for each PKI management operation.

because this is what matters more directly and also is what we refer to in the related statement

This shared secret key ssk can be reused by Alice for MAC-based protection of further messages sent to Bob within the current PKI management operation.

[DDvO]

I also suggest moving the new sentence just after the related one in 5.1.3.4, simply as follows:

Yet it MUST be fresh per each PKI management operation.

[HBrock]

I prefere refering to using a fresh ct as it is clearer and anyhow results in a fresh ssk.

[HBrock]

What do you think of this proposal as first paragraphe for Section 8.8. Each PKI entity using key encapsulation for message protection, see {{sect-5.1.3.4}}, MUST receive a fresh KEM ciphertext (ct) for each PKI management operation to derive a fresh shared secret key (ssk) for MAC-based message protection.

[HBrock]

After exchange with @DDvO this is the final proposal: Each PKI entity using key encapsulation for MAC-based message protection, see {{sect-5.1.3.4}}, MUST use a fresh KEM ciphertext (ct) for each PKI management operation to derive a fresh shared secret key (ssk).

[HBrock]

Meeting 15.6.23 As the freshnes of the (ct) cannot be ensured by Alice, it is recommended to use randomn recipNonces in the message requesting the (ct).

Each PKI entity using key encapsulation for MAC-based message protection, see [Section 5.1.3.4], MUST use a fresh shared secret key (ssk) for each PKI management operation. This can be enforced by using senderNonce and recipNonce header fields in all messages of the PKI management operation.

[HBrock]

Meeting 15.6.23 Issue can be closed after the update