Thanks all for the reviews to date. The chairs would like the tag length issue
to be resolved one way or the other before we start a call for adoption.
Please tend to that and let the working group know the resolution.
Thanks,
-- Mike & Ivo (writing as COSE chairs)
From: Brian Sipos <[email protected]>
Sent: Tuesday, March 31, 2026 5:41 AM
To: John Mattsson <[email protected]>
Cc: Russ Housley <[email protected]>; [email protected]
Subject: [COSE] Re: New Version Notification for draft-sipos-cose-cmac-01.txt
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]<mailto:[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]<mailto:[email protected]>>
Date: Monday, 23 March 2026 at 21:49
To: Brian Sipos
<[email protected]<mailto:brian.sipos%[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto: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]<mailto:[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]<mailto: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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
