Subject: [lamps] Mail regarding draft-ietf-lamps-crmf-update-algs-02

From: Mike Ounsworth <[email-masked]>
Date: Fri, 8 Jan 2021 22:38:39 +0000

Hi Russ,

TL;DR: it would be great if this draft included a PBKDF2-based MAC (we suggest PBMAC1 defined in RFC 8018). We also have a few general nit-picks about the draft.

PBKDF2-based MAC
---------------
In draft-ietf-lamps-crmf-update-algs you are updating the underlying primitives inside 4211's id-PasswordBasedMac, but we note that the overall algorithm is still PBKDF1-like, so in effect your draft is encouraging use of PBKDF1-SHA256-MAC or PBKDF1-AES-GMAC. This came up for us while going through a government crypto audit and having a FIPS-compliant PBKDF2-MAC in CMP would have made the audit easier.

For backwards compatibility reasons you probably need to leave the PBKDF1-based 4211 id-PasswordBasedMac algorithm but with updated internal algs as you've done, but can you also offer as an alternative the PBKDF2-based RFC 8018 PBMAC1? I think we're asking that in the ASN.1:

```
PKMACValue ::= SEQUENCE {
algId  AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
```
the comment "-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}" also allow PBMAC1, as well as the corresponding parameter value type.

The text in section 4.1 is already more tolerant, but explicitly mentioning (as a MAY) PBMAC1 as an alternative might make sense too:

```
algId identifies the algorithm used to compute the MAC value.  All
implementations MUST support id-PasswordBasedMAC.  The details on
this algorithm are presented in section 4.4.
```

We're working with Hendrik on draft-ietf-lamps-cmp-algorithms and it would be clean if we could reference PBMAC1 in your draft.

Other general comments
----------------------
1. Section 3.2 - The change is "All implementations MUST support SHA-256 [SHS].", which used to require SHA-1.  I don't know how this is typically done, but should your draft provide guidance on whether SHA-1 MAC is still safe to be used in backwards compatibility scenarios?

2. Section 3.3 - "A lower iteration count can be used, if automated generation produces shared secrets with high entropy".  We find the wording slightly confusing; after several re-reads we think you mean "lower than 10,000", but someone doing a quick read might interpret "lower than 100". What is your intent here?

3. Section 3.4 - There is a typo in "When this The algorithm identifier is used" ("The" should be removed)

4. Section 5 - "Therefore, the entropy of the password is crucial for the security of password-based MAC function." should be "of the password-based MAC function." ("the" missing)

5. You're copying the GMACParameters ASN.1 from your draft-ietf-lamps-cms-aes-gmac-alg, including the recommendation to use 12 bytes as default GMAC tag length. If at some point the recommendation changes to a larger value that would mean both documents need to be updated. Maybe better to leave the recommendation out of this draft and only reference the aes-gmac-alg draft? 

5a. Which brings us to a question about draft-ietf-lamps-cms-aes-gmac-alg; where did the recommendation for a 12 byte GMAC tag come from? Is that supported by the referenced standards (NIST) or by an IRTF recommendation?

---
Mike Ounsworth
Software Security Architect, Entrust

---

From: Russ Housley <[email-masked]>
Date: Sat, 9 Jan 2021 12:33:08 -0500

Mike:

Thanks for the review and thoughtful comments.

> TL;DR: it would be great if this draft included a PBKDF2-based MAC (we suggest PBMAC1 defined in RFC 8018). We also have a few general nit-picks about the draft.

I think this is a good idea.  Before I add it, I would like to know whether others agree or disagree.  More below.

> PBKDF2-based MAC

If the LAMPS WG agree with this approach, I would suggest an update to section 4.1:

OLD

      algId identifies the algorithm used to compute the MAC value.  All
      implementations MUST support id-PasswordBasedMAC.  The details on
      this algorithm are presented in section 4.4

NEW

      algId identifies the algorithm used to compute the MAC value.  All
      implementations MUST support id-PasswordBasedMAC as
      presented in section 4.4.  All implementations MAY also support
      PBMAC1 presented in Section 7.1 of [RFC8018].

> Other general comments

I'd rather not see anything about SHA-1.  The situation for Certificate Request Message Format (CRMF) is not like S/MIME.  By that I mean, one will not need to process a CRMF message many years later from an archive folder.  A CRMF message should not need to be validated after the requested certificate is issued.

> 2. Section 3.3 - "A lower iteration count can be used, if automated generation produces shared secrets with high entropy".  We find the wording slightly confusing; after several re-reads we think y…

I suggest:  As part of that tradeoff, an iteration count smaller than 10,000 can be used when automated generation produces shared secrets with high entropy.

> 3. Section 3.4 - There is a typo in "When this The algorithm identifier is used" ("The" should be removed)

Thanks.  I'll fix it.

> 4. Section 5 - "Therefore, the entropy of the password is crucial for the security of password-based MAC function." should be "of the password-based MAC function." ("the" missing)

Thanks.  I'll fix it.

> 5. You're copying the GMACParameters ASN.1 from your draft-ietf-lamps-cms-aes-gmac-alg, including the recommendation to use 12 bytes as default GMAC tag length. If at some point the recommendation…

Okay.

> 5a. Which brings us to a question about draft-ietf-lamps-cms-aes-gmac-alg; where did the recommendation for a 12 byte GMAC tag come from? Is that supported by the referenced standards (NIST) or by…

This is for alignment with RFC 5084.  I was asked this so often that I added this information to the Implementation Considerations section of draft-ietf-lamps-cms-aes-gmac-alg.

Russ

---

From: Mike Ounsworth <[email-masked]>
Date: Sat, 9 Jan 2021 18:57:20 +0000

Thanks Russ!

I think those changes fully address our concerns.

>This is for alignment with RFC 5084.  I was asked this so often that I added this information to the Implementation Considerations section of draft-ietf-lamps-cms-aes-gmac-alg.

Gotcha, thanks. Could you add that to your cms-aes-gmac draft just for the sake of an easy-to-follow citation chain? (I think 5084 is not currently in the references list)

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: January 9, 2021 11:33 AM
To: Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] Mail regarding draft-ietf-lamps-crmf-update-algs-02

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

Mike:

> implementations MUST support id-PasswordBasedMAC.  The details on this 
> algorithm are presented in section 4.4.
> ```
> 

OLD

NEW

> 3. Section 3.4 - There is a typo in "When this The algorithm 
> identifier is used" ("The" should be removed)

Thanks.  I'll fix it.

> 4. Section 5 - "Therefore, the entropy of the password is crucial for 
> the security of password-based MAC function." should be "of the 
> password-based MAC function." ("the" missing)

Thanks.  I'll fix it.

Okay.

Russ

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 9 Jan 2021 22:03:10 +0000

>    I think this is a good idea.  Before I add it, I would like to know whether others agree or disagree.  More below.

I agree with your changes.

>    I'd rather not see anything about SHA-1.  The situation for Certificate Request Message Format (CRMF) is not like S/MIME.  By that I mean, one will not need to process a CRMF message many years…

Strongly agree.

---

From: Mike Ounsworth <[email-masked]>
Date: Sat, 9 Jan 2021 23:37:46 +0000

> Strongly agree.  

What about scenarios where the CA is receiving cert reqs from legacy clients that are still using SHA1? ... I suppose you're opting to say out of that debate and leave the decision of whether or not to reject up to the implementation / configuration?

---
Mike Ounsworth

-----Original Message-----
From: Salz, Rich <[email-masked]> 
Sent: January 9, 2021 4:03 PM
To: Russ Housley <[email-masked]>; Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] Mail regarding draft-ietf-lamps-crmf-update-algs-02

Strongly agree.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 10 Jan 2021 03:44:32 +0000

>    What about scenarios where the CA is receiving cert reqs from legacy clients that are still using SHA1?
There are zillions of instances where businesses don't follow RFC's.  This will be another one.  No big deal.

> ... I suppose you're opting to say out of that debate and leave the decision of whether or not to reject up to the implementation / configuration?

Unh yeah.  Is that a problem?

---

From: Mike Ounsworth <[email-masked]>
Date: Sun, 10 Jan 2021 04:41:05 +0000

Nope, no problem, just clarifying.
________________________________
From: Salz, Rich <[email-masked]>
Sent: Saturday, January 9, 2021 9:44:32 PM
To: Mike Ounsworth <[email-masked]>; Russ Housley <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] Mail regarding draft-ietf-lamps-crmf-update-algs-02

---

From: Russ Housley <[email-masked]>
Date: Sun, 10 Jan 2021 15:06:53 -0500

> On Jan 9, 2021, at 6:37 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 

In that case, the clients conform to RFC 4211, but they do not conform to the update.

The CA will have to decide if it is willing to support SHA1.  I'd actually be surprised is any still do so now.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 11 Jan 2021 07:20:55 +0000

Thanks Mike and Russ for your proposal.

> > TL;DR: it would be great if this draft included a PBKDF2-based MAC (we
> suggest PBMAC1 defined in RFC 8018). We also have a few general nit-picks
> about the draft.
> 

I support this approach. 
After discussing this with Mike, I also plan to add PBMAC1 to CMP Algorithms.
May be I should also add this to CMP Updates to explicitly open RFC 4210 Section 5.1.3.1 to also support PBMAC1 next to id-PasswordBasedMAC.

Hendrik

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 11 Jan 2021 09:55:53 +0100

>From the product side, it's easier to support legacy algorithms than to
forbid them, as SHA-1 is yet long from being removed from cryptographic
libraries. We made a survey last year with customers, if we could remove
SHA-1 support completely, and it's still a few years out before it's
possible to generically completely forbid in products it seems.

Configuration for a specific CA is a different thing of course. Internal
legacy CAs still support SHA-1 in many organizations.

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Jan 2021 10:39:38 -0500

> On Jan 11, 2021, at 2:20 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 

Yes, it makes sense to include PBMAC1 as an alternative algorithm in the update to RFC 4210 section 5.1.3.1.

Russ