Reminder - public comments on draft FIPS 203, 204, and 205 due November 22nd

[Moody, Dustin (Fed)]

Everyone,

If you have any comments on the draft PQC FIPS, please send them to us.  The deadline is tomorrow, November 22nd, 2023.  (See below for how to submit the comments. ) 

Dustin Moody

NIST PQC

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

NIST requests comments on the initial public drafts of three Federal Information Processing Standards (FIPS): 

1. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard 
2. FIPS 204, Module-Lattice-Based Digital Signature Standard 
3. FIPS 205, Stateless Hash-Based Digital Signature Standard 

These proposed standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers, which threaten the security of current standards. The three algorithms specified in these standards are each derived from different submissions to the NIST Post-Quantum Cryptography Standardization Project.  

The public comment period for these three drafts is open through November 22, 2023. See the publication details to download the drafts and for information on submitting comments. 

*** 

Draft FIPS 203 specifies a cryptographic scheme called the Module-Lattice-Based Key-Encapsulation Mechanism Standard which is derived from the CRYSTALS-KYBER submission. A key encapsulation mechanism (KEM) is a particular type of key establishment scheme that can be used to establish a shared secret key between two parties communicating over a public channel. Current NIST-approved key establishment schemes are specified in NIST Special Publication (SP) 800-56A, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm-Based Cryptography, and SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography.  

The drafts of FIPS 204 and 205 each specify digital signature schemes, which are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. FIPS 204 specifies the Module-Lattice-Based Digital Signature Standard, which is derived from CRYSTALS-Dilithium submission. FIPS 205 specifies the Stateless Hash-Based Digital Signature Standard derived from the SPHINCS⁺ submission. Current NIST-approved digital signature schemes are specified in FIPS 186-5, Digital Signature Standard, and SP 800-208, Recommendation for Stateful Hash-based Signature Schemes. NIST is also developing a FIPS that specifies a digital signature algorithm derived from FALCON as an additional alternative to these standards. 

 
Comments about these drafts may be submitted electronically via the following email addresses: 

   FIPS 203: fips-203-comments@nist.gov
   FIPS 204: fips-204-comments@nist.gov
   FIPS 205: fips-205-comments@nist.gov

 

All relevant comments received by the deadline of November 22, 2023 will be published electronically at https://csrc.nist.gov and www.regulations.gov without change or redaction, so commenters should not include information they do not wish to be posted (e.g., personal or confidential business information). Comments that contain profanity, vulgarity, threats, or other inappropriate language or content will not be posted or considered. 

 

After the comment period closes, NIST will analyze the comments, make changes to the documents as appropriate, and then propose the drafts FIPS 203, FIPS 204, and FIPS 205 to the Secretary of Commerce for approval. 

[Falko Strenzke]

The following proposal is a result of the recent discussion on the LAMPS list about safe signature-separability defences and safe optional pre-hashing for the PQC signature schemes with contributions from David Cooper, Markku Saarinen, Darren Johnson and others. However, with this specific form of proposal I still can only claim to speak for myself.

I propose to build the following two features into ML-DSA (FIPS 204) and SLH-DSA (FIPS 205):

1. Introduction of a binary flag in the algorithm’s interface that gives domain separation between the two uses of directly signing the message and signing the hash of the message (pre-hashing).
2. Introduction of a context string into the algorithm’s interface of a length between 0 and 255 octets that allows the protocol or application to define a custom domain separation string.

This proposal is meant to be equivalent to the construction of the respective features of Ed25519ctx/Ed25519ph or Ed448/Ed448ph in RFC 8032.

The reason for the first point is the need to avoid any ambiguity with respect to what is the signed message given the alternate options of direct-signing and sign-pre-hashed-message. When lacking this domain separation feature in ML-DSA, protocols that allow both variants and cannot provide authentic information about the variant during signature verification will be subjected to signature forgery attacks.

The reason for the second point is that currently there are plans to design composite signature schemes that fulfil non-separability notions, i.e. make it impossible that a signature is stripped from the set of signatures in a composite signature and the remaining signature(s) appear as (a) valid signature(s) of the message. Existing protocols that cannot provide for authentic information about the nature (composite/standalone) of the signature algorithm during verification can achieve non-separability with a means of domain separation in the signature algorithm. The protocol can thus use the context string to ensure domain separation between composite and standalone use and possibly realize further security features such as domain separation between applications.

- Falko

Am 21.11.23 um 14:43 schrieb 'Moody, Dustin (Fed)' via pqc-forum:

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB8669AB417CBE43E1D44F4C61E5BBA%40SA1PR09MB8669.namprd09.prod.outlook.com.

--

MTG AG
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000 24
E-Mail: falko.s...@mtg.de
Web: mtg.de

Follow us

---

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy

[Andreas Hülsing]

+1

I think this is a good compromise.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8660d27a-2098-42de-a5d5-91813c140023%40mtg.de.

[Taylor R Campbell]

> Date: Wed, 22 Nov 2023 13:42:10 +0100
> From: Falko Strenzke <falko.s...@mtg.de>

>
> I propose to build the following two features into ML-DSA (FIPS 204) and
> SLH-DSA (FIPS 205):
>

> 1. Introduction of a binary flag in the algorithm's interface that

> gives domain separation between the two uses of directly signing the
> message and signing the hash of the message (pre-hashing).

> 2. Introduction of a context string into the algorithm's interface of a

> length between 0 and 255 octets that allows the protocol or
> application to define a custom domain separation string.

The only safe way to reuse a signing key across protocols is to design
or analyze the protocols jointly in the first place. This doesn't
help to do that; it only makes the interface unnecessarily complicated
and harder for engineers to work with it, which is bad for security.

Any set of protocols being designed jointly can simply use a
particular format to disambiguate messages that the key signs so the
domains of the individual protocols are separated anyway. Any set of
protocols _not_ being designed jointly is just as much at risk of
collision in domain separation context strings as in the formatting of
the body of a message leading to forgeries by confusion.

This isn't to say that the principle of domain separation for reuse of
a key is a bad idea -- it's just that baking a particular mechanism
for it into the signature scheme interface isn't needed to achieve
domain separation in practice, and hurts by adding unnecessary
complexity to a foundational interface.

[Falko Strenzke]

Hi Taylor,

Am 22.11.23 um 16:04 schrieb Taylor R Campbell:

Date: Wed, 22 Nov 2023 13:42:10 +0100
From: Falko Strenzke <falko.s...@mtg.de>

I propose to build the following two features into ML-DSA (FIPS 204) and 
SLH-DSA (FIPS 205):

 1. Introduction of a binary flag in the algorithm's interface that
    gives domain separation between the two uses of directly signing the
    message and signing the hash of the message (pre-hashing).
 2. Introduction of a context string into the algorithm's interface of a
    length between 0 and 255 octets that allows the protocol or
    application to define a custom domain separation string.

The only safe way to reuse a signing key across protocols is to design
or analyze the protocols jointly in the first place.  This doesn't
help to do that; it only makes the interface unnecessarily complicated
and harder for engineers to work with it, which is bad for security.

Any set of protocols being designed jointly can simply use a
particular format to disambiguate messages that the key signs so the
domains of the individual protocols are separated anyway.  Any set of
protocols _not_ being designed jointly is just as much at risk of
collision in domain separation context strings as in the formatting of
the body of a message leading to forgeries by confusion.

I think it should be clear that I am not proposing to NIST a mechanism for domain separation between protocols. I am proposing a *generic* mechanism for domain separation. I mentioned application separation just as an example, we can also remove that clause from the the proposal – that doesn't alter the proposal at all.

And I don't think it makes sense to discuss the proper way for domain separation between application protocols here on this list.

This isn't to say that the principle of domain separation for reuse of
a key is a bad idea -- it's just that baking a particular mechanism
for it into the signature scheme interface isn't needed to achieve
domain separation in practice, and hurts by adding unnecessary
complexity to a foundational interface.

Yes, it is needed in the signature scheme if a protocol as of yet doesn't already feed any context information into the signature digest. This can be easily understood: The old version of the protocol uses sign(hash(M). If the new version changes anything about what is fed to hash(), then downgrading to the old version leads to a valid signature for a message that was never signed and thus a signature forgery vulnerability.

This is just the problem we currently have with CMS. My proposal is made out of this necessity.

Regarding the unnecessary complexity you claim, I don't agree. The domain separation inputs should have defaults. For instance the context string in RFC 8032 is per default an empty string. Thus cryptographic libraries can provide a conventional interface signature = sign(message, key) and the context information can be provided through a specialised interface.

- Falko

[Moody, Dustin (Fed)]

Note -   when responding to this thread, please do not cc to fips-204-comments and fips-205 (unless you really wish to).  If you wish to send comments to NIST, please email the comments directly to us at those addresses.  

---

From: pqc-...@list.nist.gov on behalf of Falko Strenzke
Sent: Wednesday, November 22, 2023 10:40 AM
To: Taylor R Campbell
Cc: Moody, Dustin (Fed); pqc-forum; fips-204-comments; fips-205-comments
Subject: Re: [pqc-forum] Reminder - public comments on draft FIPS 203, 204, and 205 due November 22nd

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5d5eaace-e57f-49f1-ad5a-4b99693056b8%40mtg.de.

[D P]

Dear NIST team,

>>>After the comment period closes, NIST will analyze the comments, make changes to the documents as appropriate, and then propose the drafts FIPS 203, FIPS 204, and FIPS 205 to the Secretary of Commerce for approval. 

Can you please let us know when approximately NIST would be making these changes and proposing? Thanks in advance!

On Tuesday, November 21, 2023 at 5:43:33 AM UTC-8 Moody, Dustin (Fed) wrote:

Everyone,

If you have any comments on the draft PQC FIPS, please send them to us.  The deadline is tomorrow, November 22nd, 2023.  (See below for how to submit the comments. ) 

Dustin Moody

NIST PQC

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

NIST requests comments on the initial public drafts of three Federal Information Processing Standards (FIPS): 

1. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard 
2. FIPS 204, Module-Lattice-Based Digital Signature Standard 
3. FIPS 205, Stateless Hash-Based Digital Signature Standard 

These proposed standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers, which threaten the security of current standards. The three algorithms specified in these standards are each derived from different submissions to the NIST Post-Quantum Cryptography Standardization Project.  

The public comment period for these three drafts is open through November 22, 2023. See the publication details to download the drafts and for information on submitting comments. 

*** 

Draft FIPS 203 specifies a cryptographic scheme called the Module-Lattice-Based Key-Encapsulation Mechanism Standard which is derived from the CRYSTALS-KYBER submission. A key encapsulation mechanism (KEM) is a particular type of key establishment scheme that can be used to establish a shared secret key between two parties communicating over a public channel. Current NIST-approved key establishment schemes are specified in NIST Special Publication (SP) 800-56A, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm-Based Cryptography, and SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography.  

The drafts of FIPS 204 and 205 each specify digital signature schemes, which are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. FIPS 204 specifies the Module-Lattice-Based Digital Signature Standard, which is derived from CRYSTALS-Dilithium submission. FIPS 205 specifies the Stateless Hash-Based Digital Signature Standard derived from the SPHINCS⁺ submission. Current NIST-approved digital signature schemes are specified in FIPS 186-5, Digital Signature Standard, and SP 800-208, Recommendation for Stateful Hash-based Signature Schemes. NIST is also developing a FIPS that specifies a digital signature algorithm derived from FALCON as an additional alternative to these standards. 

 
Comments about these drafts may be submitted electronically via the following email addresses: 

   FIPS 203: fips-203...@nist.gov
   FIPS 204: fips-204...@nist.gov
   FIPS 205: fips-205...@nist.gov

 

[Simon Hoerder]

Hi,

On 22/11/2023 13:42, Falko Strenzke wrote:
[...]
> 1. Introduction of a binary flag in the algorithm’s interface that

> gives domain separation between the two uses of directly signing the
> message and signing the hash of the message (pre-hashing).

> 2. Introduction of a context string into the algorithm’s interface of a

> length between 0 and 255 octets that allows the protocol or
> application to define a custom domain separation string.

[...]
Why is there a need for two separate domain separation features? I can
see why having the second one might be nice but having two seems
unnecessarily complex.

Also, I'm not sure whether domain separation (and key reuse across
protocols) has been looked into sufficiently for the new algorithms to
encourage it at this point. It's certainly not my area of expertise and
I may have missed discussions of this but I can't recall it ever coming
up on the mailing list. I'd appreciate if someone could point me towards
the relevant security proofs to understand better what we'd be gaining
from domain separation and what the pitfalls (if any) are.

On the off chance that there aren't sufficient security proofs yet, it's
maybe an algorithm feature that should be deferred to a SP800-xxx. I'd
be ok if, for example, FIPS 204 says:
The version with
[ML-DSA.KeyGen(), ML-DSA.Sign(sk, M), ML-DSA.Verify(pk, M, σ )]
is the basic algorithm but we may want add a version
[ML-DSA.KeyGen(ds_flag), ML-DSA.Sign(sk, M, ds_str),
ML-DSA.Verify(pk, M, σ, ds_str)]
with domain separation at a later point in time via SP800-xxx."

Best,
Simon

[Markku-Juhani O. Saarinen]

On Thursday, November 23, 2023 at 10:05:08 AM UTC Simon Hoerder wrote:

(..)

On the off chance that there aren't sufficient security proofs yet, it's
maybe an algorithm feature that should be deferred to a SP800-xxx. I'd
be ok if, for example, FIPS 204 says:
The version with
[ML-DSA.KeyGen(), ML-DSA.Sign(sk, M), ML-DSA.Verify(pk, M, σ )]
is the basic algorithm but we may want add a version
[ML-DSA.KeyGen(ds_flag), ML-DSA.Sign(sk, M, ds_str),
ML-DSA.Verify(pk, M, σ, ds_str)]
with domain separation at a later point in time via SP800-xxx."

Hi Simon,

Note that it is difficult to defer domain separation for "later," specifically in the case of message hashing and digital signatures. If one allows Sign(sk, M) for all M, then that's basically the entire input space taken; you can't partition M into different domains later. One would at least need to reserve a single input byte, say Sign(sk, 0x00 || M), and state that future specifications may define inputs with a nonzero initial byte. It is easy to argue ("prove") that the additional initial byte does not make the scheme less secure than the original scheme that allowed all inputs, including zero. This is how domain separation works.

I guess this necessity (that one can't retroactively split input spaces) led to the last-minute one-byte change from the original Keccak to SHA3/SHAKE back in 2015. While this change was not much appreciated at the time (it came in late), in retrospect, it was perhaps the last opportunity to turn SHA3 into a whole family of domain-separated XOFs, hashes, MACs, etc rather than just a fixed-length hash. If NIST had defined Keccak-256(M) as SHA3-256, then we could not have had domain-separated SHAKE, so in my opinion, it was definitely worth it. The change was literally just in one input byte, but that one input byte allowed domain separation between different functions. Kyber especially makes use of this.

As for proofs, what is sure is that the current IPD text with ad hoc provisions for pre-hashed inputs without domain separation has security issues. You can't prove something secure if it isn't: These options were not present in the original academic publications (or their proofs), and they violate the preimage security claimed for SPHINCS+ and BUFF properties claimed for Dilihtium. If one interprets them to mean that one can interchangeably use M and H(M), then that leads to existential forgeries -- a violation of EUF-CMA, the security definition for essentially all modern signature schemes.

I can see that you have a ds_flag in KeyGen. If one wants to go this route and have separate schemes for "plain" and "domain-separated" functions, the flag should affect verify and signature functions too. However, there are applications -- notably PKI -- where we prefer to map an "identity" to a private key. It would be preferable if the same SPHINCS+ key could be used both in applications where the entire signed message fits in memory (practically required in "pure" variant), and where a streaming hash function can be used ("prehash."). Domain separation in input would allow this. I'd personally prefer to avoid this complexity and have a single, maximally useful primitive.

Anyway, if it ends up being two separate schemes, then I'd think that the streaming-enabled version will win the popularity contest with SPHINCS+ -- that's why I proposed it to be the default (with the H(pk || M) modification to address collision attacks and BUFF properties.) For Dilithium, I'd prefer the default to be the original proposal, as all the security proofs apply to it, and in the case of Dilithium, the original behavior doesn't have the message-in-memory complication.

Cheers,

-markku

Best,
Simon

[Falko Strenzke]

Hi Simon,

Am 23.11.23 um 11:04 schrieb Simon Hoerder:

Hi,

On 22/11/2023 13:42, Falko Strenzke wrote:
[...]

 1. Introduction of a binary flag in the algorithm’s interface that
    gives domain separation between the two uses of directly signing the
    message and signing the hash of the message (pre-hashing).
 2. Introduction of a context string into the algorithm’s interface of a
    length between 0 and 255 octets that allows the protocol or
    application to define a custom domain separation string.

[...]
Why is there a need for two separate domain separation features? I can see why having the second one might be nice but having two seems unnecessarily complex.

Agreed, the generic one would be sufficient. Also, actually it is at least in principle possible for a protocol to distinguish the direct signing from pre-hashing by means of context to be prefixed to the digested message for the new schemes in both cases. However, having the flag built into the algorithm might make it less error prone for protocols to use it.

But to allow non-separable PQ/T composite signatures a means of domain separation is needed that is compatible with existing traditional schemes. This applies to those protocols that don't feed any context into the message digest, such as X.509 and CMS signatures. By introducing the generic context in the PQC algorithms such composite signatures could then be built straightforwardly at least from EdDSA and ML-DSA. That is not solving the problem of these protocols completely but at least provides what is possible. That is the thought behind this proposal.

Again I want to point out that there is no consensus in LAMPS for this proposal of mine and I cannot predict whether it is going to be used there given the limited class of traditional algorithms that are compatible with it. But as long as the logic behind it is valid it might turn out to be useful at least for certain protocols.

Regarding security proofs I cannot contribute anything, and I expect that NIST would build in only sufficiently validated constructions.

- Falko

Also, I'm not sure whether domain separation (and key reuse across protocols) has been looked into sufficiently for the new algorithms to encourage it at this point. It's certainly not my area of expertise and I may have missed discussions of this but I can't recall it ever coming up on the mailing list. I'd appreciate if someone could point me towards the relevant security proofs to understand better what we'd be gaining from domain separation and what the pitfalls (if any) are.

On the off chance that there aren't sufficient security proofs yet, it's maybe an algorithm feature that should be deferred to a SP800-xxx. I'd be ok if, for example, FIPS 204 says:
   The version with
   [ML-DSA.KeyGen(), ML-DSA.Sign(sk, M), ML-DSA.Verify(pk, M, σ )]
   is the basic algorithm but we may want add a version
   [ML-DSA.KeyGen(ds_flag), ML-DSA.Sign(sk, M, ds_str), ML-DSA.Verify(pk, M, σ, ds_str)]
   with domain separation at a later point in time via SP800-xxx."

Best,
Simon

[Simon Hoerder]

Hi Markku,

On 23/11/2023 12:32, Markku-Juhani O. Saarinen wrote:
> On Thursday, November 23, 2023 at 10:05:08 AM UTC Simon Hoerder wrote:
>
> (..)
> On the off chance that there aren't sufficient security proofs yet,
> it's
> maybe an algorithm feature that should be deferred to a SP800-xxx. I'd
> be ok if, for example, FIPS 204 says:
> The version with
> [ML-DSA.KeyGen(), ML-DSA.Sign(sk, M), ML-DSA.Verify(pk, M, σ )]
> is the basic algorithm but we may want add a version
> [ML-DSA.KeyGen(ds_flag), ML-DSA.Sign(sk, M, ds_str),
> ML-DSA.Verify(pk, M, σ, ds_str)]
> with domain separation at a later point in time via SP800-xxx."
>
>
> Hi Simon,
>
> Note that it is difficult to defer domain separation for "later,"
> specifically in the case of message hashing and digital signatures. If
> one allows Sign(sk, M) for all M, then that's basically the entire input
> space taken; you can't partition M into different domains later. One
> would at least need to reserve a single input byte, say Sign(sk, 0x00 ||
> M), and state that future specifications may define inputs with a
> nonzero initial byte. It is easy to argue ("prove") that the additional
> initial byte does not make the scheme less secure than the original
> scheme that allowed all inputs, including zero. This is how domain
> separation works.

That's perfectly fine as far as I'm concerned.

> I guess this necessity (that one can't retroactively split input spaces)
> led to the last-minute one-byte change from the original Keccak to
> SHA3/SHAKE back in 2015. While this change was not much appreciated at
> the time (it came in late), in retrospect, it was perhaps the last
> opportunity to turn SHA3 into a whole family of domain-separated XOFs,
> hashes, MACs, etc rather than just a fixed-length hash. If NIST had
> defined Keccak-256(M) as SHA3-256, then we could not have had
> domain-separated SHAKE, so in my opinion, it was definitely worth it.
> The change was literally just in one input byte, but that one input byte
> allowed domain separation between different functions. Kyber especially
> makes use of this.

I see two major differences compared to SHA3/SHAKE here:
1. Both ML-DSA and SLH-DSA are keyed functions where the keys usually
already provide a limited sense of domain separation -- different
keys for different usages / protocols. (Not enough to meet the LAMPS
requirements as I understand from Falko, though.)
2. Hash functions and XOFs have more flexible applications than
signature algorithms as they're often used as PRFs.

> As for proofs, what is sure is that the current IPD text with ad hoc
> provisions for pre-hashed inputs without domain separation has security
> issues. You can't prove something secure if it isn't: These options were
> not present in the original academic publications (or their proofs), and
> they violate the preimage security claimed for SPHINCS+ and BUFF
> properties claimed for Dilihtium. If one interprets them to mean that
> one can interchangeably use M and H(M), then that leads to existential
> forgeries -- a violation of EUF-CMA, the security definition for
> essentially all modern signature schemes.

I am honestly quite torn about these last minute changes in general. I
can perfectly understand the motivation for some of them and I
understand it's better to get as close to perfection as possible now
instead of going through the hassle to update a FIPS document (and
deployed crypto) later. On the other hand, last minute changes tend to
invite stupid mistakes, delay roll-out and undermine public confidence
if they're not properly accounted for in security proofs.

> I can see that you have a ds_flag in KeyGen. If one wants to go this
> route and have separate schemes for "plain" and "domain-separated"
> functions, the flag should affect verify and signature functions too.
> However, there are applications -- notably PKI -- where we prefer to map
> an "identity" to a private key. It would be preferable if the same
> SPHINCS+ key could be used both in applications where the entire signed
> message fits in memory (practically required in "pure" variant), and
> where a streaming hash function can be used ("prehash."). Domain
> separation in input would allow this. I'd personally prefer to avoid
> this complexity and have a single, maximally useful primitive.

The main purpose I intended for the ds_flag is that keys generated for
the plain scheme can't be used (from a key management perspective) in
the domain separated version and vice versa. I would imagine CAVP/CMVP
troubles if there is no mechanism to distinguish between the two modes
in key handling. Mathematical consequences of the flag (e.g., mixing it
into hash inputs) are entirely optional as far as I'm concerned; I
personally don't see a need for it at the moment but I'd like to see the
whole domain separation scenario analyzed more carefully.

> Anyway, if it ends up being two separate schemes, then I'd think that
> the streaming-enabled version will win the popularity contest with
> SPHINCS+ -- that's why I proposed it to be the default (with the H(pk ||
> M) modification to address collision attacks and BUFF properties.) For
> Dilithium, I'd prefer the default to be the original proposal, as all
> the security proofs apply to it, and in the case of Dilithium, the
> original behavior doesn't have the message-in-memory complication.
>
> Cheers,
> -markku

I prefer to keep it simple: A digital signature algorithm should support
signing for all input strings up to a ridiculously large limit. If an
application or protocol wants to sign the output of a hash function that
shouldn't cause security issues at the algorithm level. Same if it wants
to sign a permutation of values, partial messages or the same message
twice. The application / protocol needs to understand what is being
signed and what isn't and needs to model its security accordingly but
the digital signature algorithm shouldn't run into security issues if it
gets something weird to sign. Everything else is just inviting trouble.

Best,
Simon