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

[Russ Housley <[e-mail]>]

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