John, The phrasing of the abstract with all of the expanded abbreviations can be cleaned up to avoid confusion, I understand the misreading here.
About the reuse and effective tag lengths, this is very valuable to know. My use definitely involves key reuse similar to Russ' reference to IPsec. Given fixed AES block size and that analysis it seems like that would justify a 96-bit truncated tag both for parity with IPsec use and to allow a more controlled, smaller q factor. Regarding your comment about "E_k(0^128) is not special" I don't understand what is meant in terms of what would actually go into a specific consideration. Could you propose some RFC-compatible text that you feel would capture the consideration? For the other feedback, I have proposed updates [1]. If you can confirm that these address your feedback that would be helpful. Thanks, Brian S. [1] https://author-tools.ietf.org/diff?doc_1=draft-sipos-cose-cmac&url_2=https://briansipos.github.io/cose-cmac/draft-sipos-cose-cmac.txt&raw=1 On Mon, Mar 30, 2026 at 2:53 AM John Mattsson <[email protected]> wrote: > draft-sipos-cose-cmac-01: > >This document registers code points for using the Advanced Encryption > Standard (AES) block cipher in Cipher-based Message Authentication Code > (CMAC) mode within CBOR Object Signing and Encryption (COSE) messages. > > Can a MAC algorithm really be used in these structures? RFC 9052 seems > quite clear: "MAC algorithms are used in the COSE_Mac and COSE_Mac0 > structures.". > > --- > > Russ Housley wrote: > >Why do you think 64 bit authentication tags are desirable? I would be > much more comfortable with 96 bits. > > We should probably try to limit the number of options. The security > properties of CMAC/CBC-MAC/HMAC depends very much on if the key is reused > or not and if the tag is truncated or not. If you use a fresh key for each > MAC, CMAC is great. If you reuse the key, untruncated CMAC gives a false > sense of security and waste a lot of bytes. The narrow block size of AES is > a problem and severely limits the security of AES-CMAC in these scenarios. > > --- > > Regardless of the tag length, if key reuse is permitted, the security > properties under repeated use of the same MAC key need to be discussed. I > think the draft need to specify limits on the message length l, the number > of generation queries q, and the number of verification queries v. > > As long as l^2 <= q, my understanding is that the integrity advantage is ≈ > v / 2^t + q^2 / 2^128 and since a single successful full-tag forgery allows > an attacker to generate an unbounded number of additional forgeries, the > expected number of successful forgeries is ≈ v / 2^t + v * q^2 / 2^128. See > [1]. > > Truncated tags behave largely as expected: they provide approximately t > bits of integrity up to a certain bound on q. By contrast, the security of > untruncated tags degrade quickly and effectively provide 128-bit security > only for the first message. > > Do we need key reuse? Without key reuse, the security properties are > simple: a t-bit tag provides t bits of integrity. > > --- > > A security consideration missing from NIST SP 800-38B is that is that > E_k(0^128) is not special. Revealing any bits of any X, E_k(X) pair breaks > the security, see [1]. This should be explicitly stated in the security > considerations. > > Cheers, > John Preuß Mattsson > > [1] Ericsson comments on 800-38B “The CMAC Mode for Authentication” > > https://emanjon.github.io/NIST-comments/2024%20-%20SP%20800-38B%20and%20800-38C.pdf > > *From: *Russ Housley <[email protected]> > *Date: *Monday, 23 March 2026 at 21:49 > *To: *Brian Sipos <[email protected]> > *Cc: *[email protected] <[email protected]> > *Subject: *[COSE] Re: New Version Notification for > draft-sipos-cose-cmac-01.txt > > Brian: > > Why do you think 64 bit authentication tags are desirable? I would be > much more comfortable with 96 bits. > > Russ > > > On Mar 23, 2026, at 10:47 AM, Brian Sipos <[email protected]> > wrote: > > COSE WG, > I have updated the individual draft referenced below based on the feedback > so far. For the explanatory updates I think the new text is more clear > about what is meant and about which sections some statements belong in. > Part of this update adds truncated MAC tags, as suggested, which align with > the strengths of existing registered MAC algorithms. > > With these changes, and from comments received so far, I think this draft > is ready for an adoption call. Thanks for the support so far! > > Brian S. > > ---------- Forwarded message --------- > From: <[email protected]> > Date: Mon, Mar 23, 2026 at 10:30 AM > Subject: New Version Notification for draft-sipos-cose-cmac-01.txt > To: Brian Sipos <[email protected]> > > > A new version of Internet-Draft draft-sipos-cose-cmac-01.txt has been > successfully submitted by Brian Sipos and posted to the > IETF repository. > > Name: draft-sipos-cose-cmac > Revision: 01 > Title: AES-CMAC for COSE > Date: 2026-03-23 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/archive/id/draft-sipos-cose-cmac-01.txt > Status: https://datatracker.ietf.org/doc/draft-sipos-cose-cmac/ > HTML: https://www.ietf.org/archive/id/draft-sipos-cose-cmac-01.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-sipos-cose-cmac > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-sipos-cose-cmac-01 > > Abstract: > > This document registers code points for using the Advanced Encryption > Standard (AES) block cipher in Cipher-based Message Authentication > Code (CMAC) mode within CBOR Object Signing and Encryption (COSE) > messages. Specifically, these uses are for computing authentication > tag values with no additional parameters. > > > > The IETF Secretariat > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
