Re: [lamps] Mail regarding draft-ietf-lamps-cmp-algorithms

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

Lijun

Thank you for explaining your requests.

I am open to also add SHA3 and I see your points regarding PKCS#11 support. But, currently from the SHA3-family only SHAKE128 and SHAKE256 are specified for use in X.509 and CMS. Therefore, you should rise your request to support SHA3 to the LAMPS mailing list and possibly submit a draft on this.

Thank you for the reference. I will cover RSASSA-PSS as alternative to PKCS#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed during the WG meeting, you should also bring this request to the attention of the group, to get a joined decision.

Anyhow, the document dose not aim to specify an exclusive list of algorithms to support. The goal is to have at least one set of algorithms as main line and one as successor. The document should also cove the most widely used algorithms. As for usage in CMP, the algorithms to support in CMP implementations strongly depend on the certificates to be used by the CMP endpoints for authentication and on the certificates to manage.

I copied the WG mailing list to this conversation, to bring you valuable point also to their attention.
Any feedback from the group is of course welcome.

Best regards,
Hendrik

Von: Lijun Liao <[e-mail]>
Gesendet: Montag, 14. Dezember 2020 22:09
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[e-mail]>
Cc: Russ Housley <[e-mail]>; [e-mail]
Betreff: Re: Mail regarding draft-ietf-lamps-cmp-algorithms

Another issue, in the meeting minutes of IETF 109, datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fminutes-109-lamps-00&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cefc83cd1b17e4580d06208d8a0747b32%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637435769436155584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ozaYtHQmvLib1VlKpZLuriL97MTXZqHCLHpOkrhoXdo%3D&reserved=0>

"Current key transport algorithms is PKCS#1 V1.5 and RSAES-OAEP. Russ has
not seen RSAES-OAEP in the wild. Hendrik will remove RSAES-OAEP."

Be careful while removing RSAES-OAEP, the BSI cryptographic recommendations of 2020 (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bsi.bund.de%2FSharedDocs%2FDownloads%2FEN%2FBSI%2FPublications%2FTechGuidelines%2FTG02102%2FBSI-TR-02102-1.html&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cefc83cd1b17e4580d06208d8a0747b32%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637435769436165577%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=27%2B9VsJhXMcH2lRn2yxh4icvomXM7RGQ%2FcDvVF7%2F8sI%3D&reserved=0>) deprecates the usage of PKCS#1 v1.5 for the encryption (also for the signature), and suggests RSAES-OAEP instead.

At page 18:

"RSA with PKCS1v1.5 padding: In principle, usage of this padding format is encouraged
neither for encryption nor for signature applications, since RSA-OAEP respectively RSA-
PSS offer more solid theoretical security guarantees. Moreover, RSA implementations with
PKCS1v1.5 padding turned out to be more susceptible to attacks exploiting side-channel
information or implementation errors."

And at page 38:

"Encryption and Decryption:

...
Usage of the older PKCS#1v1.5 paddings is not recommended, as in this context variations
of the Bleichenbacher attack [17] have repeatedly turned out to be a problem, see e.g. [20] for a
recent example."

- Lijun

On Mon, Dec 14, 2020 at 8:36 PM Lijun Liao <[e-mail]<mailto:[e-mail]>> wrote:
As specified in RFC Section 10.1.6, "Key derivation algorithms convert a password or shared secret value into a key-encryption key", in my opinion, it is the correct location to specify the HKDF to derive from shared secret. This is very useful in IoT areas, since it is much quicker than the PBKDF (no iteration is required in HKDF).

Regard SHA3, I agree that from aspect of functionality, SHAKE can replace SHA3 completely. But if considering the current PKCS#11 specification,  SHA3 is defined as the hash algorithm together with the raw signature mechanism RSA, DSA and ECDSA, and is also in HMAC, HKDF,  but SHAKE only in HKDF.

Considering PKCS#11 is widely used, and currently SHA3s are the approved algorithms, but shake still not, if SHA3 is excluded from the specification,  for a very  long time, we will keep to use only the sha2.

Please also note that the industrial / commercial CA/RA use FIPS 140 certified HSMs, and SHAKEs are not in the approved list.

So please reconsider to add the support of SHA3.

Best regards
Lijun

Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>> schrieb am Mo., 14. Dez. 2020, 17:27:
Russ, Lijun

@Russ, is it OK to use a HKDF as keyDerivationAlgorithm in PasswordRecipientInfo to solve Lijuns scenario?

@Lijun, here is the link to the meeting minutes of IETF 109, datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fminutes-109-lamps-00&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cefc83cd1b17e4580d06208d8a0747b32%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637435769436165577%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BiEbeoC4ZW0849dD4Fs4XjKQe%2FNekDH%2Br6FeLMnR3fs%3D&reserved=0>.
Unfortunately the discussion SHAKE vs. SHA3 is not documented in the minutes.
I remember the discussion, that SHAKE offers mor flexibility than SHA3, but SHA3 does not offer more security than SHAKE. But I do not fully remember the discussion.

@Russ, can you give Lijun the background, why SHA3 is not sued for X.509 and CMS, but SHAKE.

- Hendrik


Von: Lijun Liao <[e-mail]<mailto:[e-mail]>>
Gesendet: Montag, 14. Dezember 2020 15:02
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Betreff: Re: Mail regarding draft-ietf-lamps-cmp-algorithms

Dear Hendrik,

Related to the HKDF, there are Scenarios where bot CA and CMP client share secret other than passwords, 1) the secret is not qualified for the encryption / decryption, e.g.  the 16 byte secret but they want to use AES 256; 2) or they do not want to use the secret as direct key to protect the secret.

Related to the SHA3, could you please share the meeting notes, if permitted.

Best regards
Lijun

Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>> schrieb am Mo., 14. Dez. 2020, 07:53:
Dear Lijun

Thank you very much for your review.
Currently I am preparing the next update to address the guidance from IETF109.
See my comments below.


Von: Lijun Liao <[e-mail]<mailto:[e-mail]>>
Gesendet: Samstag, 12. Dezember 2020 22:05
An: [e-mail]<mailto:[e-mail]>
Betreff: Mail regarding draft-ietf-lamps-cmp-algorithms

Dear authors,

here some comments on this draft:

1. Editorial error in Section 2.1. SHA2

"The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512
produce a 224-bit are identified by the following object identifiers
(OIDs)"

Only the SHA-224 produces 224-bit output. It is better to remove the text "produce a 224-bit".

[Bro] I have removed this sentence.

2. Editorial error in Section 3. Signature Algorithms

"Signature algorithm identifiers are located in ... signatureAlgorithm field of p10cr, ..."
"Signature values are located in ... signature field of p10cr, ..."

p10cr should be corrected to CertificationRequest.

[Bro] Thank you. I will have to check this, but I think you are right. Finally the p10cr message type contains the CertificationRequest.

3. Signature algorithm
Please also consider the Ed25519 and Ed448 (see RFC 8410)

[Bro] I added them.

4. Hash algorithm in MAC, Signature algorithm and PBKDF2
Please also consider SHA3 (and SHAKE).

[Bro] After discussion at IETF109 it was decided to add SHAKE and not to add SHA3, similar to other protocols and formats like X.509 and CMS.

5. Key derivation algorithms
Please also consider HKDF.

[Bro] Currently there is only a password-based key derivation required. If I add symmetric key management technique, I would also need to add a symmetric key based algorithm.
May be I have overlooked something. Where do you want to use the HKDF?

6. ECDH
Please consider X25519 and X448 (see RFC 8410)

[Bro] I added them.

Hendrik


--
Lijun Liao