Managing SignatureAlgorithms from configuration in the age of providers

[beldmit]

I use openssl master with #22779 (rebased, see #22779 (comment)) applied and make tests with oqsprovider. I have SignatureAlgorithms configured in the config file I test against.

Current behavior is:

• When no SignatureAlgorithms are present in the config, tests pass and any algorithm works.
• When list of well-known SignatureAlgorithms is specified, tests fails as algorithms provided by oqsprovider are not allowed
• When we add any unknown name to the SignatureAlgorithms, any algorithm works
• When we add a known provider-based name to the SignatureAlgorithms, the added algorithm (and I think, classic ones also) works, the other doesn't
• When we add a known provider-based name to the SignatureAlgorithms as optional (with preceding ? as implemented by Ignore unknown sigalgs and groups in the configuration #23050), this algorithm (and I think, classic ones also) works, the other don't

I have the following questions:

1. Does this behavior meets our implementation expectations? (Probably yes)
2. Is this behavior reasonable? I'm not so sure because an arbitrary unrecognized string silently disabling any limitations doesn't look reasonable to me and requires a system administrator to pay more attention to what providers are installed and distinguish between OpenSSL native providers (and algorithms) and 3rd-party.
3. What is the best behavior here?

[beldmit]

I tag people presumably interested in proper behavior here @baentsch @tomato42 @t184256

[t184256]

If the current behaviour incentivises ?-prefixing all the values to protect oneself from accidentally failing open, that's non-ideal indeed.

[baentsch]

If I get it right you are saying that a typo in a config disables a security feature. This to me sounds very wrong.

[baentsch]

@beldmit Would you mind sharing your config such as to use it as (or create a standalone) reproducer -- and maybe as test for eventual PR changing this behaviour?

[beldmit]

The relevant part of the config:

[ ssl_module ]
system_default = crypto_policy

[ crypto_policy ]
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224

[beldmit]

Would providing a compile-time defaults for the SignatureAlgorithms (and friends) make the situation better?

[beldmit]

@t8m it doesn't look like this to me. If we provide an arbitrary string, any algorithm becomes allowed - but if we had a default list we shouldn't override it...

[baentsch]

Hmm, a default list would tie down a configuration to one possibly solving the issue for one person but equally possibly being entirely unsuitable for another person. Additionally, such solution arguably does not fit the "age of providers" in which new SigAlgs may be dynamically added to a config without the need to recompile (where such constant as proposed would be added if I understand the proposal right). I'd think it'd be much better trying to understand the bug and fix it, e.g., by openssl shouting loudly if an unknown alg name is encountered.

[beldmit]

A default list is intended to provide some reasonable algorithm in case when an error in the config file effectively switches the limitations off

[t8m]

Error in the config file should NOT switch the limitations off if config_diagnostics = 1 is present in the config file.

What would be the "default list" based on if not on the current SECLEVEL? What is wrong with the default list being anything that is implemented culled by the SECLEVEL?

[beldmit]

I agree with this approach, but I have an impression it doesn't work this way now. I plan to make some tests and will return back

[beldmit]

@t8m, I made some experiments.

I use Fedora rawhide (OpenSSL 3.2.1 + #23050 + #22779)

I build oqsprovider from sources and run the test:

OPENSSL_MODULES=`pwd`/lib/ `pwd`/test/oqs_test_tlssig "oqsprovider" `pwd`/../test/openssl-ca.cnf `pwd`/test/tmp

The test loads the config from the command line and the system config (see #23720). System config includes crypto policies defining the SignatureAlgorithms (only classic algorithms). Both system config and the test one contain the config_diagnostics = 1 line. The test fails because PQ algorithms are disabled.

If I add a string not matching any algorithms to the crypto policy, the tests start passing. If I understand correctly, it means that any algorithm becomes available despite config_diagnostics (as OpenSSL doesn't know what is the SECLEVEL for PQ algorithms).

[beldmit]

If I eliminate system config from the scenario (copying SignatureAlgorithms to test/openssl-ca.cnf and exporting OPENSSL_CONF env variable) the behavior doesn't change. config_diagnostics has effect only when, for example, the ssl_module section is empty or smth like that