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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
