Re: [lamps] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt

Hi Mike,

> "no more than 2^64 signatures" apply equally to all security levels?

Yes, 2^64 was a requirement for the NIST PQ Project Signature submissions and all SPHINCS+ parameters were generated with that in mind.

Btw, NIST has indicated that it may consider SPHINCS+ parameters for <2^64 signatures which will lead to smaller trees and better SPHINCS+ performance, so it would be a good thing from a practical standpoint. But we are not sure yet if that will come to fruition or not.

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Mike Ounsworth
Sent: Friday, August 19, 2022 6:49 PM
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>; Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
Subject: RE: [EXTERNAL][lamps] [EXTERNAL] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Also, dumb question: does "no more than 2^64 signatures" apply equally to all security levels? If not, can you give a layman's explanation for why not (and maybe include it in the draft?)

---
Mike Ounsworth
________________________________
From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> on behalf of Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org<mailto:Mike.Ounsworth=40entrust.com@dmarc.ietf.org>>
Sent: Friday, August 19, 2022 4:35:23 PM
To: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; LAMPS <spasm@ietf.org<mailto:spasm@ietf.org>>
Subject: Re: [lamps] [EXTERNAL] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt

I support this document. Here is my review:

1.
Section 2: " The corresponding FIPS public keys are the leaves in k binary trees." Is that a typo? What does the Federal Information Processing Standards have to do with these leaf nodes?

2.
The "WOTS+" acronym should probably be expanded.

3.
The paragraph starting "A SPHINCS+ signature consists of..." is likely rather confusing to someone not already an expert in this. Perhaps some ascii art depicting both the subtree relationships, as well as showing which nodes are involved in a given signature would be illustrative?

4.
The intro paragraph of section 3 says "The AlgorithmIdentifier for an SPHINCS+ public key uses *the* id-alg-sphincs-plus object identifier" ... emphasis on "*THE* id-alg-sphincs-plus OID", implying there's a single one, but in the ASN.1 definitions you have:

   IDENTIFIER id-alg-sphincs-plus-128
   IDENTIFIER id-alg-sphincs-plus-192
   IDENTIFIER id-alg-sphincs-plus-256

I assume the opening paragraph should read "... uses one of the id-alg-sphincs-plus-* object identifiers"?

5.
I see the asn.1 module has the above OIDs as TBDs; I assume they will eventually cross-reference NIST-assigned OIDs?

Can I request you stick in temporary OIDs for now for interoperable prototyping?

6.

  "The SPHINCS+ public key value is an OCTET STRING.  (Should we say something more here about the size?)"

I vote "No", but you should include an appendix with a PEM-encoded pub key, priv key, and signature over the string "The quick brown fox jumps over... you know what" (nod to OQS [footnote1]) for each security level; size can be inferred from the sample data.

7.
Section 4:

  "   IF (signed attributes are absent)
      THEN SPHINCS+_Sign(content)
      ELSE message-digest attribute = Hash(content);
           SPHINCS+_Sign(DER(SignedAttributes)) "

Naïve question: is this business of what string you're actually signing not already covered by the CMS spec? Seems a bit odd to have protocol logic in an algorithm spec.

8.
Section 5:

  " Along with the private key, the implementation MUST keep track of which leaf nodes in the tree have been used.  Loss of integrity of this tracking data can cause a one-time key to be used more than once.  As a result, when a private key and the tracking data are stored on non-volatile media ..."

Uhh, that seems copy/pasted from a stateful HBS draft, isn't the whole point of SPHICS+ that that not be the case?

9.
Section 5:

   "A SPHINCS+ tree MUST NOT be used for more than 2^64 signing operations."

This sentence probably needs expanding; horizontally-scaled instances using copies of the same keys, or backup-and-restore scenarios are gonna make it super annoying to track how many signatures a given key has performed. Needing a centralized usage counter pretty much kills scalability; and requires disaster recovery sites to have unique keys from the primary site.

Granted, 2^64 is _a lot_, and if you're building a system that's gonna have anywhere near that amount of throughput, then you probably have bigger scalability issues to solve first. Most people will never be anywhere close to 2^64 signatures and are safe to completely ignore this security consideration.

[Footnote1]: https://urldefense.com/v3/__https://github.com/open-quantum-safe/oqs-provider/blob/b159e4fe659e2d9e57a30435f9d8f5ab11533597/test/oqs_test_signatures.c*L41__;Iw!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1Q1ookb1w$<https://urldefense.com/v3/__https:/github.com/open-quantum-safe/oqs-provider/blob/b159e4fe659e2d9e57a30435f9d8f5ab11533597/test/oqs_test_signatures.c*L41__;Iw!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1Q1ookb1w$>
---
Mike Ounsworth

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Russ Housley
Sent: August 19, 2022 2:35 PM
To: LAMPS <spasm@ietf.org<mailto:spasm@ietf.org>>
Subject: [EXTERNAL] [lamps] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt

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

______________________________________________________________________

A new version of I-D, draft-housley-lamps-cms-sphincs-plus-00.txt
has been successfully submitted by Russ Housley and posted to the IETF repository.

Name:           draft-housley-lamps-cms-sphincs-plus
Revision:       00
Title:          Use of the SPHINCS+ Signature Algorithm in the Cryptographic Message Syntax (CMS)
Document date:  2022-08-19
Group:          Individual Submission
Pages:          11
URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.txt__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAJ84GYsN$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.txt__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAJ84GYsN$>
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-housley-lamps-cms-sphincs-plus/__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAAqcmAJ0$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-housley-lamps-cms-sphincs-plus/__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAAqcmAJ0$>
Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.html__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAGRbuc3g$<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.html__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAGRbuc3g$>
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sphincs-plus__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAHRh0nHN$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sphincs-plus__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAHRh0nHN$>

Abstract:
  SPHINCS+ is a stateless hash-based signature scheme.  This document
  specifies the conventions for using the SPHINCS+ stateless hash-based
  signature algorithm with the Cryptographic Message Syntax (CMS).  In
  addition, the algorithm identifier and public key syntax are
  provided.

_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haACt-2oqH$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haACt-2oqH$>
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.

_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1SnKI0s3g$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1SnKI0s3g$>