Subject: [lamps] Genart last call review of draft-ietf-lamps-crmf-update-algs-04

From: Ines Robles via Datatracker <[email-masked]>
Date: Fri, 26 Mar 2021 08:21:16 -0700

Reviewer: Ines Robles
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-crmf-update-algs-04
Reviewer: Ines Robles
Review Date: 2021-03-26
IETF LC End Date: 2021-03-26
IESG Telechat date: Not scheduled for a telechat

Summary:

The document updates the cryptographic algorithm requirements for the
Password-Based Message Authentication Code in the Internet X.509 Public Key
Infrastructure Certificate Request Message Format (CRMF).

The document is well written, I have minor comments/questions to the authors.

Major Issues: None

Minor Issues: None

Nits/Comments:

1- Introduction: "however, these algorithms are no longer
   considered the best choices. " => It would be nice to add 1 or more
   sentences explaining why they are no longer the best choices

2- Page 3: "id-PasswordBasedMAC as presented in Section 4.4 of this document"
It should be perhaps be "id-PasswordBasedMAC as presented in Section 4.4 of
[RFC4211]" ?

3- If this document does not present privacy considerations, should it be
explicitly mentioned in Section 6?

4- Since the new updates include the use of PBMAC1, HMAC-SHA256, AES-GMAC AES.
Should Section 6 include considerations about them or point to place where to
find them? e.g. For information on security considerations for PBMAC1 see
[rfc8018#section-8].

Thank you for this document,

Ines.

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Mar 2021 15:27:04 -0400

Ines Robles:

Thank you for the careful review and comments.

>   sentences explaining why they are no longer the best choices

I suggest:

   This document updates the cryptographic algorithm requirements for
   the Password-Based Message Authentication Code (MAC) in the Internet
   X.509 Public Key Infrastructure Certificate Request Message Format
   (CRMF) [RFC4211].  The algorithms specified in [RFC4211] were
   appropriate in 2005; however, these algorithms are no longer
   considered the best choices:

   *  HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much
      stronger alternatives [RFC6194].

   *  DES-MAC [PKCS11] provides 56 bits of security, which is no longer
      considered secure [WITHDRAW].

   *  Triple-DES-MAC [PKCS11] provides 112 bits of security, which is
      now deprecated [TRANSIT].

   This update specifies algorithms that are more appropriate today.

With these references:

   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
              Considerations for the SHA-0 and SHA-1 Message-Digest
              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
              <https://www.rfc-editor.org/info/rfc6194>.

   [TRANSIT]  National Institute of Standards and Technology,
              "Transitioning the use of cryptographic algorithms and key
              lengths", NIST SP 800-131Ar2, March 2019.

   [WITHDRAW] National Institute of Standards and Technology, "NIST
              Withdraws Outdated Data Encryption Standard", 2 June 2005.

> It should be perhaps be "id-PasswordBasedMAC as presented in Section 4.4 of

I was thinking of the NEW text appearing in the "updated" RFC 4211.  Your suggestion is more clear.

> explicitly mentioned in Section 6?

I do not agree.  A document that simply modernized the mandatory-to-implement cryptographic algorithm in not the place to introduce the privacy considerations for CRMF.

> find them? e.g. For information on security considerations for PBMAC1 see

Good idea.  I suggest:

   Please see [RFC8018] for security considerations related to PBMAC1.

   Please see [HMAC] and [SHS] for security considerations related to
   HMAC-SHA256.

   Please see [AES] and [GMAC] for security considerations related to
   AES-GMAC.

Russ

---

From: Ines Robles <[email-masked]>
Date: Fri, 26 Mar 2021 22:06:53 +0200

Hi Russ,

Thank you very much for addressing my comments promptly. I am ok with your
proposals.

BR,

Ines

On Fri, Mar 26, 2021 at 9:27 PM Russ Housley <[email-masked]> wrote:

> I do not agree.  A document that simply modernized the
> mandatory-to-implement cryptographic algorithm in not the place to
> introduce the privacy considerations for CRMF.
>