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

[Roman Danyliw <[e-mail]>]

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.

Roman