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

[Mike Ounsworth <[e-mail]>]

Hi Roman!

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

A couple thoughts here:

1. I don't think we have any language stating that these profiles are requirements. The language (from Hendrik's slides for Monday) is the column header " Recommended for
managing keys up to". It's a nit-pick, I know.

2. An implementation doing AES256+RSA2048 exceeds the profile that recommends AES128+RSA2048. That's fine, unless there's an on-the-wire interop concern here? For example if an existing CMP client handling RSA2048 keys only has an AES256 implementation and would barf if the server suddenly started using AES128? I assume that sort of thing would be caught in product testing.

Or is your concern more to do with optics / security proofs / FIPS and CMVP style certifications if we lower the required AES strength of a profile?


---
Mike Ounsworth

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Roman Danyliw
Sent: November 5, 2021 7:32 AM
To: Brockhaus, Hendrik <[e-mail]>
Cc: LAMPS WG <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07

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

______________________________________________________________________
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

_______________________________________________
Spasm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!NwM9O539Oeipl6SKmy8vetAtfLdTV8T7NN9QpjDYy5RiXvDZT0IQ7XKRqzUi-rLAqsGMhhAHTg$
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.