Remove hash binding for signatures

[wussler]

Proposal following discussion on the list: https://mailarchive.ietf.org/arch/msg/openpgp/8qr7qJdo6N_4eGklR6hTovtWltU/

[fluppe2]

IMHO the hash bindings should not be dropped, but altered if CNSA 2.0 compliance is of utter importance.

That is, the dropped table should state SHA-384 instead of SHA3-256, and likewise SHA-512 instead of SHA3-512. On that basis compliance to CNSA 2.0 should be explicitely claimed in the "Binding hashes in signatures with signature algorithms" (keep the previous title).

Dropping the table means less guidance for implementers, which will result in confusion.

Explicit is better than implicit.

[wussler]

Dropping the table means less guidance for implementers, which will result in confusion.

Explicit is better than implicit.

This is indeed true, but we don't want to disallow using SHA3 for everyone, that would also be quite nonsense IMO.
Not binding the hashes is consistent with the current OpenPGP behaviour: the choice of the hash algorithm is independent from the choice of the signature one.

I added a note in the security considerations about this, but maybe we can make it more explicit.

Other option, is to keep the binding but allow both SHA2 and SHA3:

{: title="Binding between ML-DSA + EdDSA and signature data digest" #tab-mldsa-hash}
Algorithm ID reference | Hash function     | Hash function ID reference
----------------------:| ----------------- | --------------------------
30                     | SHA2-256 SHA3-256 | 8, 12
31                     | SHA2-512 SHA3-512 | 10, 14

But I personally don't see the point that much

[falko-strenzke]

Dropping the table means less guidance for implementers, which will result in confusion.
Explicit is better than implicit.

This is indeed true, but we don't want to disallow using SHA3 for everyone, that would also be quite nonsense IMO. Not binding the hashes is consistent with the current OpenPGP behaviour: the choice of the hash algorithm is independent from the choice of the signature one.

I added a note in the security considerations about this, but maybe we can make it more explicit.

Other option, is to keep the binding but allow both SHA2 and SHA3:

{: title="Binding between ML-DSA + EdDSA and signature data digest" #tab-mldsa-hash}
Algorithm ID reference | Hash function     | Hash function ID reference
----------------------:| ----------------- | --------------------------
30                     | SHA2-256 SHA3-256 | 8, 12
31                     | SHA2-512 SHA3-512 | 10, 14

But I personally don't see the point that much

I think we'll indeed have to give some restrictions on the possible hash algorithms. Otherwise implementers might make weird choices. I am in favor of providing a list of allowed hash algorithms like you propose in the table above.

[fluppe2]

As I understand RFC9580 5.2.4. Computing Signatures, the hash algorithm ID is part of the trailer.

Therefore I would rather like to explicitly list the allowed options as you suggested. Keep in mind that CNSA 2.0 states "Use SHA-384 or SHA-512 for all classification levels.". I think that means SHA2-384 or SHA2-512 instead of SHA2-256 (for algorithm 30) in the table.

Also one line per combination (here with SHA2-384):
30 | SHA2-384 | 9
30 | SHA3-256 | 12
31 | SHA2-512 | 10
31 | SHA3-512 | 14

(SHA3-256 looks so odd now :-)

[TJ-91]

Since we deviate from the default OpenPGP behaviour, perhaps we should also add a statement that flexibility in the digest algorithms may hurt security when matching "too weak" hash functions. While it historically may have made sense to have flexibility, we do not see a reason to have it with the PQC algorithms.

For SLH-DSA we can even enhance the argument why using the matching SHA3 function increases security. In contast to most other signature schemes, its security relies entirely upon the security properties of a hash function and no additional hardness assumptions about other mathematical problems are required. Thus, the attack surface is (relatively speaking) much more affected when using a different hash function.

The reason why I think it makes sense to add these things is that previously we had a clear story ("match the internally used hash algorithms"), but now we are more lenient with ML-DSA and it's less consistent. However, if you think the current state is sufficient, I'm also fine with it. Also, it can be part of the security considerations, I think.

[falko-strenzke]

Since we deviate from the default OpenPGP behaviour, perhaps we should also add a statement that flexibility in the digest algorithms may hurt security when matching "too weak" hash functions. While it historically may have made sense to have flexibility, we do not see a reason to have it with the PQC algorithms.

For SLH-DSA we can even enhance the argument why using the matching SHA3 function increases security. In contast to most other signature schemes, its security relies entirely upon the security properties of a hash function and no additional hardness assumptions about other mathematical problems are required. Thus, the attack surface is (relatively speaking) much more affected when using a different hash function.

The reason why I think it makes sense to add these things is that previously we had a clear story ("match the internally used hash algorithms"), but now we are more lenient with ML-DSA and it's less consistent. However, if you think the current state is sufficient, I'm also fine with it. Also, it can be part of the security considerations, I think.

What I see as a concrete formal loss is that we loose the resistance against digest substitution attacks. But I think this is not an issue that has any practical relevance.

[fluppe2]

See 0c8d0a1 for a proposal. I stripped the security considerations down to an essential information.

Looking at the Pre-Hash Variants for ML-DSA that have received an OID (see https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration), I wonder if we want to settle with SHA3-512 and SHA2-512 for all ML-DSA-composites. That would make the list more comprehensive and we could drop the section "Binding hashes ..." in the security considerations completely.

[fluppe2]

This looks good to me. Did a rebase (hopefully didn't mess up anything) and some minor cleanups. Please comment and/or approve.

Do we need to specify now the hash function that has been used for the signature data digest in test vector A.4?

[wussler]

I think the refactor messed it up the display a little, but looking at the diff it looks good to me. Can't approve because am author