Skip to main content

Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-kemri-08

Yes

Roman Danyliw

No Objection

Éric Vyncke
Jim Guichard
(Andrew Alston)
(Erik Kline)
(John Scudder)
(Martin Duke)
(Robert Wilton)

Note: This ballot was opened for revision 08 and is now closed.

Roman Danyliw
Yes
Éric Vyncke
No Objection
Jim Guichard
No Objection
Paul Wouters Former IESG member
Yes
Yes (2024-03-05) Sent
Thanks to Brian Weis for the SecDir review. I think there are some good
suggestions in there. Please take those into consideration:

https://datatracker.ietf.org/doc/review-ietf-lamps-cms-kemri-06-secdir-lc-weis-2023-10-24/

I had one question myself:

        Implementations that do not support the ukm field SHOULD
        gracefully discontinue processing when the ukm field is present.

Can this field be present and empty/zero-length ? If so, does this
affect the SHOULD above?
Andrew Alston Former IESG member
No Objection
No Objection () Not sent

                            
Erik Kline Former IESG member
No Objection
No Objection () Not sent

                            
Francesca Palombini Former IESG member
No Objection
No Objection (2024-03-06) Not sent
Thank you for the work on this document.

Many thanks to Sean Turner for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Uo8K4UDxV3qpy_RYd5mL2KTjgik/.
John Scudder Former IESG member
No Objection
No Objection () Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection () Not sent

                            
Murray Kucherawy Former IESG member
No Objection
No Objection (2024-03-06) Sent
===

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?
Robert Wilton Former IESG member
No Objection
No Objection () Not sent

                            
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection (2024-03-06) Not sent
Thanks for working on this specification.