[COSE] Re: [EXT] Re: AES-GMAC in COSE

["Sipos, Brian J." <[e-mail]>]

All,

I now have a first non-internet-draft version of a GMAC and KMAC registration [1] available for browsing and initial feedback. After that feedback I can post this as a proper internet draft. Right now, the code point registrations follow existing AES-related parameters for 128, 192, 256 -bit keys and full-length tags. I don’t have particular interested in shortened tag lengths so didn’t put in allocations for them like some of the existing COSE MAC algos have. I also don’t have strong feelings about useful key lengths.

 

John, I understand your comments about the IV uniqueness vs. randomness and if you have some specific language for Section 2.1 that is welcome. Otherwise I will add a requirement to forbid random IV values. Is there any stronger recommendation for how to generate non-random IVs?

 

Russ, if you would like to be added as a coauthor and want to steer the KMAC details just let me know from where I can take your up-to-date contact details. Right now, this allocation does make use of the KMAC customization string similar to the IPsec draft. But if there is some guidance or benefit to avoiding the customization that would be useful to know.

 

[1] https://briansipos.github.io/cose-gmac-kmac/draft-sipos-cose-gmac-kmac.html

 

From: John Mattsson <[e-mail]> 
Sent: Thursday, October 31, 2024 12:47 PM
To: Sipos, Brian J. <[e-mail]>; Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: [COSE] Re: [EXT] Re: AES-GMAC in COSE

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Hi,

 

Specifying KMAC is a great idea, we (Ericsson) are planning to transition as much as possible to SHA-3/SHAKE/cSHAKE/KMAC in the transition to PQC, which ML-KEM and ML-DSA use internally. I am happy to help with any introduction of SHAKE and KMAC in IETF protocols. I assume the document will specify KMAC128 and KMAC256. A remaining question is what the tag length should be and if several tag lengths should be specified. 

 

(Regarding the IPsec draft: I don’t see any use of HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512, these are very inefficient constructions. I don’t think there are any reasons to use anything else than KMAC. Similarly, the requirement on signature algorithms should be SHAKE. Also, NIST is soon disallowing SHA3-224.)

https://datatracker.ietf.org/doc/rfc8692/

https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd

 

Regarding AES-GMAC, I think AES-192 could be skipped. I agree the tag length should be 128-bits for GMAC. In addition to stating “Within the scope of any content-authentication key, the AES-GMAC nonce value MUST be unique.” I think the draft should explicitly state that random nonces MUST not be used. As I brought in my comments to NIST, SP 800-38C (CCM) states that the nonce shall be unique but there are still implementations that use CCM with a 11-byte random nonce as the default…

https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-38c-initial-public-comments-2024.pdf

 

Cheers,

John

 

From: Sipos, Brian J. <[e-mail] <mailto:[e-mail]> >
Date: Thursday, 31 October 2024 at 16:56
To: Russ Housley <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Subject: [COSE] Re: [EXT] Re: AES-GMAC in COSE

Russ,

I looked into KMAC and it seems like it can also be included as a set of fully specified algorithms parameterized like you mentioned. Other proposed uses in IPsec [3] do make use of different customization strings, which might apply in this situation but I’ll leave that detail to other experts.

 

I have an initial draft going through internal release review. After that I can add you as coauthor if you’d like and can point me to (e.g. a recent draft that has) your contact info.

 

Thanks in advance,

Brian S.

 

[3]  <https://datatracker.ietf.org/doc/draft-salter-ipsecme-sha3/> https://datatracker.ietf.org/doc/draft-salter-ipsecme-sha3/

 

From: Russ Housley <[e-mail] <mailto:[e-mail]> > 
Sent: Friday, July 19, 2024 1:49 PM
To: Sipos, Brian J. <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: [EXT] Re: [COSE] AES-GMAC in COSE

 

Brian:

 

I am willing to assist on the GMAC document.

 

Any reason not to do KMAC as well?  See RFC 8702.   I would think that KMAC with SHAKE128 (outputs 256 bits with no customization string) and KMAC with SHAKE256 (outputs 512 bitswith no customization string).  I am willing to consider other parameter choices if people see a need.

 

Russ

 

On Jul 19, 2024, at 11:28 AM, Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > wrote:

 

All,

I was looking in the COSE algorithms registry [1] for any existing allocations for GMAC uses but don’t see any. My reason for looking was that in some hardware-accelerated environments AES-GCM is faster than HMAC processing, so a GMAC would also benefit from the acceleration.

I expect that a COSE use of AES-GMAC would look similar to the use in CMS [2] except that COSE algorithms typically combine options like authentication tag size into a single code point, so an initial thought would be max-length tags like: AES-GMAC 128/128, AES-GMAC 192/128, AES-GMAC 256/128

 

Would there be WG interest in allocating GMAC algorithms in the near-term time supporting max-length tags?

Thanks,

Brian S.

 

[1]  <https://www.iana.org/assignments/cose/cose.xhtml#algorithms> https://www.iana.org/assignments/cose/cose.xhtml#algorithms

[2]  <https://datatracker.ietf.org/doc/html/rfc9044> https://datatracker.ietf.org/doc/html/rfc9044