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

[Orie Steele <[e-mail]>]

Russ,

I figured you had considered this : )

Perhaps a note/comment in draft-ietf-lamps-cms-cek-hkdf-sha256 findable by
searching for "kem" might save you future explanations.

You have addressed my comments.

OS

On Thu, Mar 7, 2024 at 2:18 PM Russ Housley <[e-mail]> wrote:

> Murray and Orie:
>
> >> 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://datatracker.ietf.org/doc/draft-housley-lamps-cms-cek-hkdf-sha256/
> >
> > Or the algorithm integrity protection comments in:
> >
> > https://www.rfc-editor.org/rfc/rfc9459.html#section-8
> >
> > 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?
>
> When Falko first shared his attack, he suggested adding the CEK or CAEK
> algorithm identifier to KEMRecipientInfo.  I was not interested in this
> solution because it mitigated the attack for KEMs, but it leaves all of the
> other forms of RecipientInfo vulnerable.  The solution proposed in
> draft-housley-lamps-cms-cek-hkdf-sha256, which is now
> draft-ietf-lamps-cms-cek-hkdf-sha256, resolves the attack for all forms of
> RecipientInfo.
>
> Russ
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>