Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07

["Brockhaus, Hendrik" <[e-mail]>]

Roman

I aligned with Mike, John, and Hans. 
Please see our feedback on your comments regarding Section 7 and Section 9 below.

> Von: Spasm <[e-mail]> Im Auftrag von Roman Danyliw
> Gesendet: Dienstag, 26. Oktober 2021 23:49
> 
> Hi!
> 
> I did an AD review of draft-ietf-lamps-cmp-algorithms-07 with my comments
> below.  Thanks for this work to evolve CMP.
> 
> ** Section 7.  I would have benefit from a bit more clarity on the direction
> provided in this section.
> 
> -- "The following criteria will help implementers choose appropriate algorithms
> for managing certificates"
> 
> The bulleted list seems like only part of the criteria.  As a non-exhaustive list,
> additional considerations might be the capabilities of the end-point (e.g., does
> the target deployment have hardware acceleration for some, are some
> algorithms simply out of reach due to available compute or expected software
> support); or perhaps local policy or compliance requirements?
> 
> -- "The cryptographic strength of the algorithm with the lowest security."
> 
> It seems like some words are missing here.  Is the intent here to guide the
> selection towards the algorithm that provides the minimum amount of strength
> relative to the needed security requirements?

Thank you for this feedback. We propose the following changes.
In addition to that we think another table in the introduction of Section 7 listing the different algorithms sorted by its security level (bits of security) would help. We plan to present such a table during the LAMPS session for further discussion.

Old:
   The following criteria will help implementers choose appropriate
   algorithms for managing certificates:

   *  The cryptographic strength of the algorithm with the lowest
      security.

      Note: To avoid consuming too much computational resources it is
      recommended to choose a set of algorithms offering roughly the
      same level of security.

   *  The entropy of the shared secret information or password when MAC-
      based message protection is used, e.g., MSG_MAC_ALG.

   Finally, the cryptographic strength of the system SHOULD be at least
   as strong as the algorithms and keys used for the certificate being
   managed.

New:
The overall cryptographic strength of a CMP deployment will depend on
several factors, including:
 
* Algorithm profile: The overall strength of the profile will be the strength
   of the weakest algorithm it contains.
 
* Message protection: The overall strength of the CMC message protection 
   - MAC-based protection: The entropy of the shared secret information or
     password when MAC-based message protection is used, e.g.,
     MSG_MAC_ALG.
   - Signature-based protection: The strength of the key pair and signature
     algorithm when signature-based protection is used, e.g., MSG_SIG_ALG
 
* Certificates managed: Finally, the cryptographic strength of the system
   SHOULD be at least as strong as the algorithms and keys used for the
   certificate being managed.
 
To avoid consuming too much computational resources it is
recommended to choose a set of algorithms offering roughly the
same level of security. Below are provided several algorithm profiles 
which are balanced, assuming the implementor chooses MAC secrets 
and / or certificate profiles of at least equivalent strength.

> 
> ** Section 7.1.  The text in this section seems it should explicit say that it is
> updating RFC4210.
> 
> OLD
> The following table contains definitions of algorithms used within
> 
> NEW
> The following table updates the definitions of algorithms used within

I am fine with this change.

> 
> ** Section 7.1.  If an algorithm is listed in the "Change from 4210" column,
> should it be considered the equivalent of being added to the "other" column (per
> Appendix D.2 of RFC4210?  If so, please be explicit about that.

We will delete the column "Changes from 4210" and introduced two columns, "Optional" and "Deprecated". "Deprecated" contains all algorithms define in RFC 4210 Appendix D.2 which SHOLUD NOT be used any more.

> 
> ** Section 7.1.  Table 1.
> 
> -- What does it mean for PasswordBasedMac to be in both the Mandatory and
> Change-from-4210 column for the MSG_MAC_ALG row?  It was already the MTI
> in RFC4210.  Same question and situation with D-H for the PROT_ENC_ALG row.

PBMAC1 became MANDATORY and PasswordBasedMac became OPTIONAL.

> 
> -- Should 3-DES be considered "other" in MSG_MAC_ALG and PROT_SYM_ALG?

3-DES (3-key-EDE, CBC mode) became Deprecated as you proposed below.

> 
> -- Editorial.  In PROT_SYM_ALG and SYM_PENC_ALG, the "3-DES (3-key-EDE),
> CBC Mode" should read "3-DES (3-key-EDE, CBC mode)" per the text in RFC4210.

Thanks for the clarification, we can fix this.

This is the Update we propose for Section 7.1
Old
   Change from 4210: Shows the changes in the Mandatory and Other
   algorithms from RFC 4210 [RFC4210].  These are included for backwards
   compatibility considerations.

   +============+===============+==================+===================+
   |Name        |Use            | Mandatory        |Change from 4210   |
   +============+===============+==================+===================+
   |MSG_SIG_ALG |protection of  | RSA              |DSA/SHA1           |
   |            |PKI messages   |                  |Others: RSA/MD5,   |
   |            |using signature|                  |ECDSA              |
   +------------+---------------+------------------+-------------------+
   |MSG_MAC_ALG |protection of  | PasswordBasedMac |PasswordBasedMac   |
   |            |PKI messages   | (RECOMMENDED:    |Others: HMAC, X9.9 |
   |            |using MACing   | PBMAC1)          |                   |
   +------------+---------------+------------------+-------------------+
   |SYM_PENC_ALG|symmetric      | AES-wrap         |3-DES(3-key-EDE),  |
   |            |encryption of  |                  |CBC Mode           |
   |            |an end entity's|                  |Others: AES, RC5,  |
   |            |private key    |                  |CAST-128           |
   |            |where symmetric|                  |                   |
   |            |key is         |                  |                   |
   |            |distributed    |                  |                   |
   |            |out-of-band    |                  |                   |
   +------------+---------------+------------------+-------------------+
   |PROT_ENC_ALG|asymmetric     | D-H              |D-H                |
   |            |algorithm used |                  |Others: RSA, ECDH  |
   |            |for encryption |                  |                   |
   |            |of (symmetric  |                  |                   |
   |            |keys for       |                  |                   |
   |            |encryption of) |                  |                   |
   |            |private keys   |                  |                   |
   |            |transported in |                  |                   |
   |            |PKIMessages    |                  |                   |
   +------------+---------------+------------------+-------------------+
   |PROT_SYM_ALG|symmetric      | AES-CBC          |3-DES(3-key-EDE),  |
   |            |encryption     |                  |CBC Mode           |
   |            |algorithm used |                  |Others: AES, RC5,  |
   |            |for encryption |                  |CAST-128           |
   |            |of private key |                  |                   |
   |            |bits (a key of |                  |                   |
   |            |this type is   |                  |                   |
   |            |encrypted using|                  |                   |
   |            |PROT_ENC_ALG)  |                  |                   |
   +------------+---------------+------------------+-------------------+

New
Optional: Algorithms which are OPTIONAL to support

Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be used anymore

+============+===============+==========+=================+=============+
|Name        |Use            |Mandatory |Optional       |Deprecated   |
+============+===============+==========+=================+=============+
|MSG_SIG_ALG |protection of  |RSA       |ECDSA, EdDSA     |combinations |
|            |PKI messages   |          |                 |with MD5 and   |
|            |using signature|          |                 |SHA1         |
+------------+---------------+----------+-----------------+-------------+
|MSG_MAC_ALG |protection of  |PBMAC1    |PasswordBasedMac,|             |
|            |PKI messages   |          |HMAC, X9.9       |             |
|            |using MACing   |          |                 |             |
+------------+---------------+----------+-----------------+-------------+
|SYM_PENC_ALG|symmetric      |AES-wrap  |                 |3-DES        |
|            |encryption of  |          |                 |(3-key-EDE,  |
|            |an end entity's|          |                 |CBC Mode),   |
|            |private key    |          |                 |CAST-128, RC5|
|            |where symmetric|          |                 |             |
|            |key is         |          |                 |             |
|            |distributed    |          |                 |             |
|            |out-of-band    |          |                 |             |
+------------+---------------+----------+-----------------+-------------+
|PROT_ENC_ALG|asymmetric     |D-H       |ECDH, RSA        |             |
|            |algorithm used |          |                 |             |
|            |for encryption |          |                 |             |
|            |of (symmetric  |          |                 |             |
|            |keys for       |          |                 |             |
|            |encryption of) |          |                 |             |
|            |private keys   |          |                 |             |
|            |transported in |          |                 |             |
|            |PKIMessages    |          |                 |             |
+------------+---------------+----------+-----------------+-------------+
|PROT_SYM_ALG|symmetric      |AES-CBC   |                 |3-DES        |
|            |encryption     |          |                 |(3-key-EDE,  |
|            |algorithm used |          |                 |CBC Mode),   |
|            |for encryption |          |                 |CAST-128, RC5|
|            |of private key |          |                 |             |
|            |bits (a key of |          |                 |             |
|            |this type is   |          |                 |             |
|            |encrypted using|          |                 |             |
|            |PROT_ENC_ALG)  |          |                 |             |
+------------+---------------+----------+-----------------+-------------+

Currently we propose a mandatory algorithm use profile with 112bit strength. As recommendations are going from RSA2048 to RSA3072 we discussed, if it is better to make a profile mandatory offering 128 bit strength. 
Currently we also mandate to use AES256 for key-wrap and encryption for delivering centrally generated RSA2048 keys pairs. The encryption is stronger than delivered key pair. Should we mandate AES128 only?
Currently HMAC and X9.9 are listed as OPTIONAL for MSG_MAC_ALG as they were listed in RFC 4210 D.2. We propose to remove x9.9 and keep HMAC. Regarding use of HMAC we would propose adding a Security Consideration as follows.

   Symmetric key-based MAC algorithms as described in Section 6.2  MAY be 
   used as MSG_MAC_ALG.  The implementor MUST choose a suitable PRF 
   and ensure that the key  has sufficient entropy to match the overall security 
   level of the algorithm  profile. These considerations are outside the scope 
   of the profile.

@Russ and Roman, what is your opinion?

> 
> ** Section 9.  Can a reference be added for the theoretical weakness in
> PasswordBasedMac?

We are not aware of any clear description of PasswordBasedMac weakness. Therefor we propose the following change:

Old
   When using MAC-based message protection the use of PBMAC1 is
   preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known
   scrutinized algorithm, which is not true for PasswordBasedMac and
   second, there exists a theoretical weakness in PasswordBasedMac,
   where the generated MAC key can be easily distinguished from a random
   key.

New
When using MAC-based message protection the use of PBMAC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well-known scrutinized algorithm, which is not true for PasswordBasedMac. Second, the PasswordBasedMac algorithm as specified in RFC 4211 section 4.4 is essentially PBKDF1 (as defined in RFC 2898 section 5.1) with an HMAC step at the end. Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in RFC 8018. PBKDF2 is superior to PBKDF1 in an improved internal construct for iterated hashing, and in removing PBKDF1's limitation of only being able to derive keys up to the size of the underlying hash function. Additionally, PBKDF1 is not recommended for new applications as stated in Section 5 of RFC 8018 and no longer an approved algorithm by most standards bodies, and therefore presents difficulties to implementors who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with RFC 9045 which updates RFC 4211 to allow the use of PBMAC1 in CRMF.

> 
> ** Section 9.  Editorially, the first paragraph ("RFC 4210 Appendix D.2 ...) and the
> two paragraphs of "In Section 7 ..." and "To keep the list ...", seem to be saying
> the same thing.  Recommend a merge.
> 

Okay, maybe we just remove the paragraph "To keep the list of algorithms"

> ** Section 9.
> In such systems the weakened algorithms should
>    be disabled from further use.
> 
> Can this document make stronger recommendations about deprecating certain
> algorithms such as 3-DES SHA-1 with normative language rather than keeping it
> in the "other" category in the profiles?

We updated Table 1 in Section 7.1 accordingly. Use of MD5, SHA-1, 3-DES, CAST-128, and RC5 is deprecated.
Therefore we propose updating the section as follows.

Old
   It is recognized that there may be older CMP implementations in use
   that conform to the algorithm use profile from Appendix D.2 of
   RFC 4210 [RFC4210].  For example, the use of AES is now mandatory for
   PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory.  In most
   cases the newer mandatory algorithms were listed as "other"
   algorithms in RFC 4210 [RFC4210].  Therefore, it is expected that
   many CMP systems may already support the recommended algorithms in
   this specification.  In such systems the weakened algorithms should
   be disabled from further use.  If critical systems cannot be
   immediately updated to conform to the recommended algorithm use
   profile, it is recommended a plan to migrate the infrastructure to
   conforming profiles be adopted as soon as possible.

New
   It is recognized that there may be older CMP implementations in use
   that conform to the algorithm use profile from Appendix D.2 of
   RFC 4210 [RFC4210].  For example, the use of AES is now mandatory for
   PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. 
   Therefore, it is expected that
   many CMP systems may already support the recommended algorithms in
   this specification.  In such systems the weakened algorithms should
   be disabled from further use.  If critical systems cannot be
   immediately updated to conform to the recommended algorithm use
   profile, it is recommended a plan to migrate the infrastructure to
   conforming profiles be adopted as soon as possible.

Hendrik