Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-08.txt

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 2 Feb 2022 07:04:34 +0000

Russ

We are kind of stuck with the final reviews of the CMP Algorithms draft regarding SHAKE and KMAC usage.
There was a discussion on the chat during IETF 112 on this matter. The authors addressed all issued raised, but would appreciate a review by an expert.
Do you have any suggestion how to proceed?
Could you formally ask CFRG to review the open issues?

- Hendrik

> Von: Roman Danyliw <[email-masked]>
> Gesendet: Dienstag, 11. Januar 2022 19:00
> 
> Hi Hendrik!
> 
> Understood.  We'll wait for the WG review of the edits (per Quyhn) and then
> a revision minimally to remove the "TODO stubs".
> 
> Thanks,
> Roman
> 
> > -----Original Message-----
> > From: Brockhaus, Hendrik <[email-masked]>
> > Sent: Tuesday, January 11, 2022 2:33 AM
> > To: Roman Danyliw <[email-masked]>; [email-masked]
> > Cc: [email-masked]; Russ Housley <[email-masked]>
> > Subject: AW: [lamps] I-D Action:
> > draft-ietf-lamps-cmp-algorithms-08.txt
> >
> > Hello Roman
> >
> > Thank you very much for your feedback.
> >
> > The marks refer to the discussion that took place at IETF 112 in the
> > chat about how the use of SHAKE was described.
> > From that discussion, I understand that Quynh offered a review of the
> > I-D that provides the needed changes.
> > After the meeting, the authors looked more deeply into the use of hash
> > algorithms in CMP and proposed these updates.
> > We welcome any review and feedback.
> >
> > @Quyhn, if I misunderstood you, please accept my apologies.
> >
> > Hendrik
> >
> > > Von: Roman Danyliw <[email-masked]>
> > > Gesendet: Montag, 10. Januar 2022 23:18
> > >
> > > Hi Hendrik!
> > >
> > > I wanted to confirm that -08 addressed my AD Review.
> > >
> > > -09 still has markers of the form "< ToDo: This note must be checked
> > > and confirmed by experts.>"  What's the thinking on those reviews?
> > >
> > > Regards,
> > > Roman
> > >
> > > > -----Original Message-----
> > > > From: Brockhaus, Hendrik <[email-masked]>
> > > > Sent: Wednesday, December 15, 2021 8:52 AM
> > > > To: Roman Danyliw <[email-masked]>; [email-masked]; Russ
> > > > Housley <[email-masked]>
> > > > Cc: [email-masked]
> > > > Subject: AW: [lamps] I-D Action:
> > > > draft-ietf-lamps-cmp-algorithms-08.txt
> > > >
> > > > Is there anything I can do about draft-ietf-lamps-cmp-algorithms-08?
> > > >
> > > > Hendrik
> > > >
> > > > > Von: Spasm <[email-masked]> Im Auftrag von Brockhaus,
> > > > > Hendrik
> > > > > Gesendet: Mittwoch, 17. November 2021 17:38
> > > > >
> > > > > We just submitted an update of CMP Algorithms draft addressing
> > > > > the comments from Roman's AD review and the discussion at IETF
> 112.
> > > > >
> > > > > The authors appreciate any review comments, especially on the
> > > > > tables in Section 7 and the Sections on SHAKE and KMAC usage.
> > > > > @Quynh, Thank you for offering your expertise on this.
> > > > >
> > > > >    From version 07 -> 08:
> > > > >
> > > > >    *  Fixing issues from WG and AD review
> > > > >    *  Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of
> > > > >       SHAKE and KMAC and added ToDo regarding checking
> > > > > respective
> > > notes
> > > > >    *  Added two tables showing algorithms sorted by their strength to
> > > > >       Section 7 and added ToDo regarding checking theses tables
> > > > >    *  Updates the algorithm use profile in Section 7.1
> > > > >    *  Updated and added security consideration on SHAKE,
> > > > >       PasswordBasedMac, KMAC, and symmetric key-based MAC
> > > > > functions
> > > and
> > > > >       added ToDo regarding checking the security consideration
> > > > > on SHAKE
> > > > >
> > > > > Hendrik
> > > > >
> > > > > > Von: Spasm <[email-masked]> Im Auftrag von internet-
> > > > > > [email-masked]
> > > > > > Gesendet: Mittwoch, 17. November 2021 17:19
> > > > > >
> > > > > >
> > > > > > A New Internet-Draft is available from the on-line
> > > > > > Internet-Drafts
> > > > > directories.
> > > > > > This draft is a work item of the Limited Additional Mechanisms
> > > > > > for PKIX and SMIME WG of the IETF.
> > > > > >
> > > > > >         Title           : Certificate Management Protocol (CMP) Algorithms
> > > > > >         Authors         : Hendrik Brockhaus
> > > > > >                           Hans Aschauer
> > > > > >                           Mike Ounsworth
> > > > > >                           John Gray
> > > > > > 	Filename        : draft-ietf-lamps-cmp-algorithms-08.txt
> > > > > > 	Pages           : 33
> > > > > > 	Date            : 2021-11-17
> > > > > >
> > > > > > Abstract:
> > > > > >    This document updates RFC 4210 describing the conventions for
> using
> > > > > >    concrete cryptographic algorithms with the Certificate
> Management
> > > > > >    Protocol (CMP).  CMP is used to enroll and further manage the
> > > > > >    lifecycle of X.509 certificates.
> > > > > >
> > > > > >
> > > > > > The IETF datatracker status page for this draft is:
> > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2
> > > > > > F%25
> > > > > > 2F
> > > > > > da
> > > > > > ta
> > > > > > tr
> > > > > > acker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-
> > > > > >
> > > > >
> > >
> algorithms%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com
> > > > > >
> > > > >
> > > >
> > >
> >
> %7C5ea8a0eb3dfa4bcf9bc908d9a9e62669%7C38ae3bcd95794fd4addab42e14
> > > > > >
> > > > >
> > > >
> > >
> >
> 95d55a%7C1%7C0%7C637727628230195738%7CUnknown%7CTWFpbGZsb3d
> > > > > >
> > > > >
> > > >
> > >
> >
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > > > > >
> > > > >
> > > >
> > >
> >
> %7C3000&amp;sdata=5He4lH8c%2FAJq6ayV3oREbVnRcOO%2BVXqSnhR6Q6G
> > > > > > iths%3D&amp;reserved=0
> > > > > >
> > > > > > There is also an HTML version available at:
> > > > > >
> > > > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > > >
> > > > >
> > > >
> > >
> >
> i%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ca549af
> > > > > eec5e1
> > > > > >
> > > > >
> > > >
> > >
> >
> 4a21e7df08d9a9e8a7d5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
> > > > > %7C6377
> > > > > >
> > > > >
> > > >
> > >
> >
> 27638996391296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > JQIjoiV2l
> > > > > >
> > > > >
> > > >
> > >
> >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=PjR2D1U%2B1
> > > > > H24aJ7
> > > > > > ID0NyL9xAluhEQ%2F8dsbDSgf68j1I%3D&amp;reserved=0
> > > > > > etf.org%2Farchive%2Fid%2Fdraft-ietf-lamps-cmp-algorithms-
> > > > > >
> > > > >
> > >
> 08.html&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C5ea
> > > > > >
> > > > >
> > > >
> > >
> >
> 8a0eb3dfa4bcf9bc908d9a9e62669%7C38ae3bcd95794fd4addab42e1495d55a
> > > > > >
> > > > >
> > > >
> > >
> >
> %7C1%7C0%7C637727628230195738%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > > > > >
> > > > >
> > > >
> > >
> >
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > > > > >
> > > > >
> > > >
> > >
> >
> 00&amp;sdata=xiboY9LJwa9SggJQCLw62wanImVr599ykORtaKdANsQ%3D&am
> > > > > > p;reserved=0
> > > > > >
> > > > > > A diff from the previous version is available at:
> > > > > >
> > > > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > > >
> > > > >
> > > >
> > >
> >
> i%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ca549af
> > > > > eec5e1
> > > > > >
> > > > >
> > > >
> > >
> >
> 4a21e7df08d9a9e8a7d5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
> > > > > %7C6377
> > > > > >
> > > > >
> > > >
> > >
> >
> 27638996401290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > JQIjoiV2l
> > > > > >
> > > > >
> > > >
> > >
> >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Zooi7TSEyYlzp
> > > > > OvkP
> > > > > > 2E1mKUBI%2BogMYNyoFPhBmKTmpQ%3D&amp;reserved=0
> > > > > > etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-algorithms-
> > > > > >
> > > > >
> > >
> 08&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C5ea8a0e
> > > > > >
> > > > >
> > > >
> > >
> >
> b3dfa4bcf9bc908d9a9e62669%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> > > > > >
> > > > >
> > > >
> > >
> >
> %7C0%7C637727628230195738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > > > > >
> > > > >
> > > >
> > >
> >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> > > > > >
> > > > >
> > > >
> > >
> >
> mp;sdata=RdKY3lRt6uiBQfNp9dYX5cS7xePhxQmjLAj4Oafc%2Brs%3D&amp;res
> > > > > > erved=0
> > > > > >
> > > > > >
> > > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > >
> https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.
> > > > > > ie
> > > > > >
> > > > >
> > >
> tf.o%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ca54
> > > > > 9afeec
> > > > > >
> > > > >
> > > >
> > >
> >
> 5e14a21e7df08d9a9e8a7d5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> > > > > 7C0%7C6
> > > > > >
> > > > >
> > > >
> > >
> >
> 37727638996401290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> > > > > AiLCJQIjoi
> > > > > >
> > > > >
> > > >
> > >
> >
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=vMTxQS%2
> > > > > F549W%
> > > > > > 2BipLGQJIBd8jFqp0r51iM6gAX56aCF2w%3D&amp;reserved=0
> > > > > > rg%2Finternet-
> > > > > >
> > > > >
> > >
> drafts%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C5
> > > > > >
> > > > >
> > > >
> > >
> >
> ea8a0eb3dfa4bcf9bc908d9a9e62669%7C38ae3bcd95794fd4addab42e1495d5
> > > > > >
> > > >
> > 5a%7C1%7C0%7C637727628230195738%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > > >
> > > > >
> > > >
> > >
> >
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > > > > >
> > > > >
> > >
> 3000&amp;sdata=zXSo0IODxSjpyyd7Ex1bTIJa4FyhAFgRodftcPbhQo4%3D&am
> > > > > > p;reserved=0
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Spasm mailing list
> > > > > > [email-masked]
> > > > > >
> > > > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > > >
> > > > >
> > > >
> > >
> >
> i%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ca549af
> > > > > eec5e1
> > > > > >
> > > > >
> > > >
> > >
> >
> 4a21e7df08d9a9e8a7d5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
> > > > > %7C6377
> > > > > >
> > > > >
> > > >
> > >
> >
> 27638996401290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > JQIjoiV2l
> > > > > >
> > > > >
> > > >
> > >
> >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Zooi7TSEyYlzp
> > > > > OvkP
> > > > > > 2E1mKUBI%2BogMYNyoFPhBmKTmpQ%3D&amp;reserved=0
> > > > > >
> > > > >
> > >
> etf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.br
> > > > > >
> > > > >
> > > >
> > >
> >
> ockhaus%40siemens.com%7C5ea8a0eb3dfa4bcf9bc908d9a9e62669%7C38ae3
> > > > > >
> > > > >
> > > >
> > >
> >
> bcd95794fd4addab42e1495d55a%7C1%7C0%7C637727628230195738%7CUn
> > > > k
> > > > > >
> > > > >
> > > >
> > >
> >
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > > > > >
> > > > >
> > > >
> > >
> >
> haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=L%2BWY9ufwnckvUswk7Gtl0h
> > > > > > hvT%2B86SZXVT3g7%2FjSpIrI%3D&amp;reserved=0
> > > > >
> > > > > _______________________________________________
> > > > > Spasm mailing list
> > > > > [email-masked]
> > > > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > > i
> > > >
> > >
> etf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.br
> > > > >
> > > >
> > >
> >
> ockhaus%40siemens.com%7Ca549afeec5e14a21e7df08d9a9e8a7d5%7C38ae3
> > > > >
> > > >
> > >
> >
> bcd95794fd4addab42e1495d55a%7C1%7C0%7C637727638996401290%7CUn
> > > > k
> > > > >
> > > >
> > >
> >
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> > > > >
> > >
> haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XjOViJ8kLqlF5AojBwsB3Ynicjn
> > > > > A%2BjB9xzeuElQQ4C0%3D&amp;reserved=0

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 2 Feb 2022 15:52:33 +0000

To be explicit, we are asking for review by crypgographic experts about the 6 "ToDo" items in draft-ietf-lamps-cmp-algorithms. Could LAMPS ask CFRG to perform this review?

As per Appendix A: Change History:

* Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of SHAKE and KMAC and added ToDo regarding checking respective notes
* Added two tables showing algorithms sorted by their strength to Section 7 and added ToDo regarding checking theses tables
* Updated and added security consideration on SHAKE, PasswordBasedMac, KMAC, and symmetric key-based MAC functions and added ToDo regarding checking the security consideration on SHAKE

---
Mike Ounsworth

-----Original Message-----
From: Brockhaus, Hendrik <[email-masked]>
Sent: February 2, 2022 1:05 AM
To: Russ Housley <[email-masked]>
Cc: [email-masked]; Mike Ounsworth <[email-masked]>
Subject: [EXTERNAL] AW: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-08.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Russ

- Hendrik

> Understood.  We'll wait for the WG review of the edits (per Quyhn) and
> then a revision minimally to remove the "TODO stubs".
>
> Thanks,
> Roman
>
> > From that discussion, I understand that Quynh offered a review of
> > the I-D that provides the needed changes.
> > After the meeting, the authors looked more deeply into the use of
> > hash algorithms in CMP and proposed these updates.
> > > -09 still has markers of the form "< ToDo: This note must be
> > > checked and confirmed by experts.>"  What's the thinking on those reviews?
> > >
> > > Regards,
> > > Roman
> > >
> > > > > > This draft is a work item of the Limited Additional
> > > > > > Mechanisms for PKIX and SMIME WG of the IETF.
> > > > > >
> > > > > > https://urldefense.com/v3/__https://eur01.safelinks.protecti
> > > > > > on.outlook.com/?url=https*3A*2__;JSU!!FJ-Y8qCqXTj2!IBNzn0e33
> > > > > > WLpnhAo_-vU3qHz-RGmkL2wl9n_9u9M3rlS5DCU9md5-3siH8_TeevMGlE_$
> > > > > > F%25
> > > > > > 2F
> > > > > > da
> > > > > > ta
> > > > > > tr
> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!FJ-Y8qCqXTj2!IBNzn0e33WLpnhAo_-vU3qHz-RGmkL2wl9n_9u9M3rlS5DCU9md5-3siH8_TeQFWZvSr$ .
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!FJ-Y8qCqXTj2!IBNzn0e33WLpnhAo_-vU3qHz-RGmkL2wl9n_9u9M3rlS5DCU9md5-3siH8_TeQFWZvSr$ .
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=ftp*3A*2F*2Fftp__;JSUl!!FJ-Y8qCqXTj2!IBNzn0e33WLpnhAo_-vU3qHz-RGmkL2wl9n_9u9M3rlS5DCU9md5-3siH8_TeSxxROSX$ .
> > > > > > ie
> > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!FJ-Y8qCqXTj2!IBNzn0e33WLpnhAo_-vU3qHz-RGmkL2wl9n_9u9M3rlS5DCU9md5-3siH8_TeQFWZvSr$ .
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww__;JSUl!!FJ-Y8qCqXTj2!IBNzn0e33WLpnhAo_-vU3qHz-RGmkL2wl9n_9u9M3rlS5DCU9md5-3siH8_TeQFWZvSr$ .
> > > > > i
> > > >
> > >
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Feb 2022 12:00:40 -0500

Quynh:

It is my understanding that you agreed to review the paragraphs marked with ToDo in draft-ietf-lamps-cmp-algorithms-08.txt.  Can you please give us a date by which that review will be complete?  Your review is blocking the IESG processing of this document.

Thanks in advance,
 Russ

---

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Thu, 3 Feb 2022 11:50:39 +0000

Hi Russ and all,

Section 2.2

This paragraph:  "SHAKE is an extendable-output function and FIPS Pub 202
   [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
   function.  When SHAKE is used in CMP as a message digest algorithm,
   the message digested by the SHAKE function MUST be appended with the
   OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and
   "CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits
   for SHAKE128 and 512 bits for SHAKE256."   has no security issues.

The string "CMP_SHAKE128" is not needed for domain separation among the SHAKEs and SHAs since they are already domain separated with different paddings.

However, if we think that it is a domain separation for CMP with other protocols when a same SHAKE and a same message are used in different protocols, then it would be good to use such a bit string for domain separation. However, that applies to SHA2s as well when the same hash function and the same input are used in 2 different places.

If we want to save  a few bytes, I would suggest to remove the OCTET_STRINGs: "CMP_SHAKE128" and "CMP_SHAKE256".

Section 3.3.  EdDSA.

Currently, there is no official FIPS 186-5 and I don't know when there will be one.

Everything looks fine to me.

Section 6.2.3,

The "Note" in this section is not needed. An attacker can build a special hardware device for KMAC can also build a special hardware device for HMAC with a SHA2 function. Maybe KMAC is more energy efficient, but that would not stop a determined attacker because it costs more energy and a bit longer.  In term of money cost, I am not sure how to evaluate such a comparison at this time.

I think the Note should be removed.

Tables 1 and 2 in Section 7.

The sentence preceding table 1 should use the word "row" instead of "column".

Curve25519 is a curve, Ed25519 is a digital signature algorithm.

Similarly, Curve448 is a curve, Ed448 is a digital signature using Curve448.

"X25519" or "X448" are specific DH functions, not curves or digital signature algorithms.

Should use the names consistent in this section.

Section 9.

This paragraph " SHAKE is an extendable-output function and FIPS Pub 202 [NIST.FIPS.202<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms-09#ref-NIST.FIPS.202>] prohibits using SHAKE as general-purpose hash function.  To prevent known attacks SHAKE MUST only be used as hash function within CMP [RFC4210<https://datatracker.ietf.org/doc/html/rfc4210>] and CMP Updates [I-D.ietf-lamps-cmp-updates<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms-09#ref-I-D.ietf-lamps-cmp-updates>] if the output length is fixed to d=256 for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702<https://datatracker.ietf.org/doc/html/rfc8702>] and MUST NOT be used with different output lengths."  is odd to me.

The spec already requires fixed lengths of 256 and 512 for SHAKE128 and SHAKE256 respectively.

If one uses SHAKE128 and a message to produce a 256-bit and a 224-bit outputs on 2 different

executions, then the first 224 bits of the former is the same with the latter.  And, this is

the same with SHA256 when being used to produce a 256-bit and a 224-bit outputs.

There are no known security weaknesses here.  No further advice is needed.

I suggest to remove the paragraph.

As discussed for Section 6.2.3 above, this paragraph " Currently it is assumed that the advantage of a HW implementation over a SW implementation of KMAC is greater than of HMAC-SHA2. Therefore, the advantage of an attacker is greater if KMAC is used as a prf in PasswordBasedMac and PBKDF2.  For this reason, the use of KMAC as a prf in PasswordBasedMac and PBKDF2 is discouraged."   should be removed.

Let me know if there are any other places that you would like me to review.

Regards,
Quynh.

________________________________
From: Russ Housley <[email-masked]>
Sent: Wednesday, February 2, 2022 12:00 PM
To: Dang, Quynh H. (Fed) <[email-masked]>
Cc: LAMPS <[email-masked]>; Roman D. Danyliw <[email-masked]>
Subject: Quynh Action: draft-ietf-lamps-cmp-algorithms-08.txt

Quynh:

Thanks in advance,
 Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 3 Feb 2022 12:01:29 +0000

Hi Quynh

Many thanks for you feedback and comments.
I will align with the other authors and provide an update of the I-D.

Best regards,
Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Dang, Quynh H. (Fed)
Gesendet: Donnerstag, 3. Februar 2022 12:51
An: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>
Betreff: Re: [lamps] Quynh Action: draft-ietf-lamps-cmp-algorithms-08.txt

Hi Russ and all,

Section 2.2

Section 3.3.  EdDSA.

Section 6.2.3,

Section 9.

This paragraph " SHAKE is an extendable-output function and FIPS Pub 202 [NIST.FIPS.202<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-cmp-algorithms-09%23ref-NIST.FIPS.202&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb6e21a8d2d864a88d2b408d9e70b7429%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637794858677778505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GUlxJVKO9TF4mKHdNCW2Yuke%2FdqNev8KUq6F74NAlvQ%3D&reserved=0>] prohibits using SHAKE as general-purpose hash function.  To prevent known attacks SHAKE MUST only be used as hash function within CMP [RFC4210<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb6e21a8d2d864a88d2b408d9e70b7429%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637794858677778505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AIpBhGJqgqqQQo5MLN0MnCS%2BubyEo9FbhC1xKK44UJs%3D&reserved=0>] and CMP Updates [I-D.ietf-lamps-cmp-updates<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-cmp-algorithms-09%23ref-I-D.ietf-lamps-cmp-updates&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb6e21a8d2d864a88d2b408d9e70b7429%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637794858677778505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=x%2FPkY8u8JzDD%2BQJkZPI8N%2F0kVUzvek22YUAKvWnmgIc%3D&reserved=0>] if the output length is fixed to d=256 for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8702&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb6e21a8d2d864a88d2b408d9e70b7429%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637794858677778505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DkhnZhgTNS63652BEDAuvhwPozjSuqk5hDw6lomMDK8%3D&reserved=0>] and MUST NOT be used with different output lengths."  is odd to me.

Regards,
Quynh.

________________________________
From: Russ Housley <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 2, 2022 12:00 PM
To: Dang, Quynh H. (Fed) <[email-masked]<mailto:[email-masked]>>
Cc: LAMPS <[email-masked]<mailto:[email-masked]>>; Roman D. Danyliw <[email-masked]<mailto:[email-masked]>>
Subject: Quynh Action: draft-ietf-lamps-cmp-algorithms-08.txt

Quynh:

Thanks in advance,
 Russ

> Von: Roman Danyliw <[email-masked]<mailto:[email-masked]>>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 14 Feb 2022 14:07:33 +0000

Quynh

Thank you for your review and your comments.
I aligned with the co-authors and they also appreciate your proposals and we will follow your recommendations..
Below you find the changes I will implement with the next update of this draft.
I will submit the updated version today. It would be good, if you could check Table 1 and Table 2 in Section 7, if I made all necessary changes.

> The string "CMP_SHAKE128" is not needed for domain separation among the
> SHAKEs and SHAs since they are already domain separated with different
> paddings.
> 
> However, if we think that it is a domain separation for CMP with other
> protocols when a same SHAKE and a same message are used in different
> protocols, then it would be good to use such a bit string for domain
> separation. However, that applies to SHA2s as well when the same hash
> function and the same input are used in 2 different places.
> 
> If we want to save  a few bytes, I would suggest to remove the
> OCTET_STRINGs: "CMP_SHAKE128" and "CMP_SHAKE256".

OLD:
   SHAKE is an extendable-output function and FIPS Pub 202
   [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
   function.  When SHAKE is used in CMP as a message digest algorithm,
   the message digested by the SHAKE function MUST be appended with the
   OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and
   "CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits
   for SHAKE128 and 512 bits for SHAKE256.

NEW:
   SHAKE is an extendable-output function and FIPS Pub 202
   [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
   function.  When SHAKE is used in CMP as a message digest algorithm,
   the output length MUST be 256 bits for SHAKE128 and 512 bits for
   SHAKE256.

> The "Note" in this section is not needed. An attacker can build a special
> hardware device for KMAC can also build a special hardware device for
> HMAC with a SHA2 function. Maybe KMAC is more energy efficient, but that
> would not stop a determined attacker because it costs more energy and a bit
> longer.  In term of money cost, I am not sure how to evaluate such a
> comparison at this time.
> 

I will remove the note as suggested.

> The sentence preceding table 1 should use the word "row" instead of

Thank you for spotting this. I will change it.

> Should use the names consistent in this section.

I will update both tables as follows. I am sorry for the poor layout in this text-only email.

   +========+===========+=========+===============+===============+==========+
   |Bits of |Recommended|RSA / D-H|Elliptic curve |Hash function  |Symmetric |
   |security|for        |         |               |or XOF with    |encryption|
   |        |managing   |         |               |specified      |          |
   |        |keys up to |         |               |output length  |          |
   |        |           |         |               |(d)            |          |
   +========+===========+=========+===============+===============+==========+
   |112     |RSA2048    |RSA2048  |ECDSA/         |SHA224         |          |
   |        |secp224r1  |D-H(2048)|ECDH(secp224r1)|               |          |
   +--------+-----------+---------+---------------+---------------+----------+
   |128     |RSA3072    |RSA3072  |ECDSA/         |SHA256         |AES-128   |
   |        |secp256r1  |D-H(3072)|ECDH(secp256r1)|SHAKE128(d=256)|          |
   |        |Curve25519 |         |Ed25519/X25519 |               |          |
   +--------+-----------+---------+---------------+---------------+----------+
   |192     |secp384r1  |         |ECDSA/         |SHA384         |AES-192   |
   |        |           |         |ECDH(secp384r1)|               |          |
   +--------+-----------+---------+---------------+---------------+----------+
   |224     |Curve448   |         |Ed448/X448     |               |          |
   +--------+-----------+---------+---------------+---------------+----------+
   |256     |secp521r1  |         |ECDSA/         |SHA512         |AES-256   |
   |        |           |         |ECDH(secp521r1)|SHAKE256(d=512)|          |
   +--------+-----------+---------+---------------+---------------+----------+

     Table 1: Cryptographic algorithms sorted by their bits of security

   +=====+=============+===============+===============+===============+
   |Bits |Recommended  |CMP protection |Key management | Key-wrap and  |
   |of   |for managing |               |technique      | symmetric     |
   |secu-|keys up to   |               |               | encryption    |
   |rity |             |               |               |               |
   +=====+=============+===============+===============+===============+
   |     |             |MSG_SIG_ALG,   |PROT_ENC_ALG or| PROT_SYM_ALG, |
   |     |             |MSG_MAC_ALG    |KM_KA_ALG,     | SYM_PENC_ALG  |
   |     |             |               |KM_KT_ALG,     | or            |
   |     |             |               |KM_KD_ALG      | KM_KW_ALG     |
   +-----+-------------+---------------+---------------+---------------+
   |112  |RSA2048,     |RSASSA-PSS     |ESDH (2048),   |               |
   |     |secp224r1    |(2048, SHA224  |RSAES-OAEP     |               |
   |     |             |or SHAKE128),  |(2048, SHA224),|               |
   |     |             |RSAEncryption  |RSAEncryption  |               |
   |     |             |(2048, SHA224),|(2048),        |               |
   |     |             |ECDSA          |ECDH           |               |
   |     |             |(secp224r1,    |(secp224r1,    |               |
   |     |             |SHA224 or      |SHA224),       |               |
   |     |             |SHAKE128),     |PBKDF2 (HMAC-  |               |
   |     |             |PBMAC1 (HMAC-  |SHA224)        |               |
   |     |             |SHA224)        |               |               |
   +-----+-------------+---------------+---------------+---------------+
   |128  |RSA3072,     |RSASSA-PSS     |ESDH (3072),   | AES-128       |
   |     |secp256r1,   |(3072, SHA256  |RSAES-OAEP     |               |
   |     |Curve25519   |or SHAKE128),  |(3072, SHA256),|               |
   |     |             |RSAEncryption  |RSAEncryption  |               |
   |     |             |(3072, SHA256),|(3072),        |               |
   |     |             |ECDSA          |ECDH           |               |
   |     |             |(secp256r1,    |(secp256r1,    |               |
   |     |             |SHA256 or      |SHA256),       |               |
   |     |             |SHAKE128),     |X25519,        |               |
   |     |             |Ed25519        |PBKDF2 (HMAC-  |               |
   |     |             |(SHA512),      |SHA256)        |               |
   |     |             |PBMAC1 (HMAC-  |               |               |
   |     |             |SHA256)        |               |               |
   +-----+-------------+---------------+---------------+---------------+
   |192  |secp384r1    |ECDSA          |ECDH           | AES-192       |
   |     |             |(secp384r1,    |(secp384r1,    |               |
   |     |             |SHA384),       |SHA384),       |               |
   |     |             |PBMAC1 (HMAC-  |PBKDF2 (HMAC-  |               |
   |     |             |SHA384)        |SHA384)        |               |
   +-----+-------------+---------------+---------------+---------------+
   |224  |Curve448     |Ed448          |X448           |               |
   |     |             |(SHAKE256)     |               |               |
   +-----+-------------+---------------+---------------+---------------+
   |256  |secp521r1    |ECDSA          |ECDH           | AES-256       |
   |     |             |(secp521r1,    |(secp521r1,    |               |
   |     |             |SHA512 or      |SHA512),       |               |
   |     |             |SHAKE256),     |PBKDF2 (HMAC-  |               |
   |     |             |PBMAC1 (HMAC-  |SHA512)        |               |
   |     |             |SHA512)        |               |               |
   +-----+-------------+---------------+---------------+---------------+

         Table 2: Cryptographic algorithms sorted by their bits of
                         security and usage by CMP

> 
> Section 9.
> 
> This paragraph " SHAKE is an extendable-output function and FIPS Pub
> 202 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash 
> function.  To prevent known attacks SHAKE MUST only be used as hash 
> function within CMP [rfc4210] and CMP Updates [I-D.ietf-lamps-cmp- 
> updates] if the output length is fixed to d=256 for SHAKE128 and
> d=512 for SHAKE256 as described in [rfc8702] and MUST NOT be used with 
> different output lengths."  is odd to me.
> 
> If one uses SHAKE128 and a message to produce a 256-bit and a 224-bit
> outputs on 2 different executions, then the first 224 bits of the former is the
> same with the latter.  And, this is the same with SHA256 when being used to
> produce a 256-bit and a 224-bit outputs.
> 
> 

I will remove this paragraph.

> 
> As discussed for Section 6.2.3 above, this paragraph " Currently it is assumed
> that the advantage of a HW implementation over a SW implementation of
> KMAC is greater than of HMAC-SHA2. Therefore, the advantage of an
> attacker is greater if KMAC is used as a prf in PasswordBasedMac and
> PBKDF2.  For this reason, the use of KMAC as a prf in PasswordBasedMac and
> PBKDF2 is discouraged."   should be removed.

I will remove this paragraph.

Best regards,
Hendrik