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

[Roman Danyliw <[e-mail]>]

Hi!

> -----Original Message-----
> From: Brockhaus, Hendrik <[e-mail]>
> Sent: Thursday, November 4, 2021 2:04 PM
> To: Roman Danyliw <[e-mail]>
> Cc: LAMPS WG <[e-mail]>
> Subject: AW: AD review of draft-ietf-lamps-cmp-algorithms-07
> 
> 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.

Works for me.  Thanks.

> >
> > ** 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.

Thanks.

> >
> > ** 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.

That's even a better.  

> >
> > ** 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)  |          |                 |             |
> +------------+---------------+----------+-----------------+-------------+

I really like this table.  It's much clearer.

> 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?

Can you be more specific on which text says profiles have 112bits of strength and the KeyWrap+RSA guidance?  Is the 112bits implicitly derived from using RSA-2048?

AES128 + RSA2048 would be more consistent based on the principle of matching relative key strength. However, if prior specs said AES256+RSA2048, I think we should be careful about weaking the requirement regardless of consistency.

> 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.

I'm fine with keeping HMAC.  I don't really know much about the user community of X9.9.  It doesn't look like something we're recommend now.  When you say remove it, do you mean SHOULD NOT/Deprecate column?  We should also likely confirm that with the WG.

> @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.

This is much clearer.  Thanks.

> >
> > ** 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.

Thanks for the text.

Regards,
Roman

> Hendrik