[secdir] Secdir last call review of draft-ietf-cose-aes-ctr-and-cbc-04

[Daniel Migault via Datatracker <[e-mail]>]

Reviewer: Daniel Migault
Review result: Ready

Reviewer: Daniel Migault
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other

section 4 AES counter mode

In "AES encryption of (IV +1) mod 2^128" I am wondering if "mod 2^128" is
needed as I see the encryption returning a 128 bit block. That said we
understand why it is there, it is more that I am curious if there is any reason.

I am also wondering if we should mention the IV + i is called the counter block
as this is mentioned in section 8.

The following text sounded cryptic to me until I reached section 6. I suspect
that adding a reference to section 6 might be useful. The same comment applies
for CBC.

"""
Since AES-CTR cannot provide integrity protection for external
additional authenticated data, the decryptor MUST ensure that no
external additional authenticated data was supplied.
"""

section 4.2.  AES-CTR COSE Algorithm Identifiers

In the title “Algoritm” needs to be changed.

It is surprising to define a "Deprecated", but the note provides the rationale.
I am wondering if that rationale could be also mentioned in the IANA page -
this is just a suggestion.

section 5.  AES Cipher Block Chaining Mode

I believe that another reason for using integrity protection is the
vulnerability to padding oracle.