Re: [lamps] AD Review of draft-ietf-lamps-cms-kemri-07

[Russ Housley <[e-mail]>]

> On Feb 6, 2024, at 4:08 PM, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!
> 
>> -----Original Message-----
>> From: Russ Housley <[e-mail]>
>> Sent: Monday, February 5, 2024 4:06 PM
>> To: Roman Danyliw <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [lamps] AD Review of draft-ietf-lamps-cms-kemri-07
>> 
>> Warning: External Sender - do not click links or open attachments unless you
>> recognize the sender and know the content is safe.
>> 
>> 
>> Roman:
>> 
>>> Last October, I performed an AD review on -05
>> (https://mailarchive.ietf.org/arch/msg/spasm/DrkREuxsrIRWHRR4qj6yWxVufIQ
>> /).  After IETF LC, new analysis of this document was reported
>> (https://mailarchive.ietf.org/arch/msg/spasm/TTtMQlcpGRq_bThfJl-
>> HnqqGLGI/) requiring WG deliberations.  After IETF 118, this document was
>> sent back to the WG.  This document has gone through another WGLC and is
>> back to the IESG with "publication requested."
>>> 
>>> Thank you to Falko Strenzke and Johannes Roth for reporting this attach
>> against CMS and the WG's timely response.  This is a second AD review on -07.
>> Feedback is below.
>>> 
>>> ** Section 1
>>> 
>>>  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.
>>> 
>>> Should normative MUST be used to describe these three crucial properties of
>> the environment?
>> 
>> I think this is saying where KEMRecipientInfo is appropriate to apply. Mostly,
>> people that write RFCs that specify the conventions for a particular KEM will
>> need to make sure they understand these requirements.  For example,
>> rfc5990bis.  Likewise, the authors of the document that is written for ML-KEM
>> will need to consider these too.
> 
> I think we agree.  My synthesize is that the above is roughly an applicability statement for KEMRecipientInfo -- that is, normative constraints on how/where the solution can be applied.  For that reason, I was wondering if this met the bar the RFC2119 language.

There are MUST and SHOULD statements in the Security Considerations around these points.  I worry that elevating the sentences in the Introduction will cause a conflict with the careful choices that were made in the Security Considerations.

A MUST example: 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.

A SHOULD example: The KDF SHOULD offer at least the security level of the KEM.

These topics overlap with that Introductory material.

Russ