Please switch from HMAC to EVP MAC APIs

[xnox]

It seems like KMAC implementation on Linux uses EVP MAC APIs which is good.

The HMAC implementation seems to use obsolete HMAC_ APIs, which will be removed soon. And in 3.0.0 are wrappers around digest API.

The issue is that HMAC APIs bypass provider framework and checks available there.

In certain configurations MD5 can be allowed as digest, but blocked as HMAC.

This works correctly in python (which uses EVP APIs for hash and HMAC), but not with dotnet right now (which uses EVP digest effectively for both hash and HMAC).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[xnox]

I don't believe this is a security issue per se. But it is to do with native crypto provider and which bindings are in use.

[xnox]

Adding this will be a bit convoluted, if compatibility with OpenSSL before 3.0.0 is desired to remain in place.

CryptoNative_EvpMacInit will need extending to set OSSL_MAC_PARAM_DIGEST and binding for EVP_MAC_CTX_get_mac_size need to be added. And then plumb it all up. And conveniently OSSL_MAC_PARAM_DIGEST is a string, and not EVP_MD id, however luckily matches the string dotnet digest names.

Trying to draft this seems a bit futile for me to complete, and I am already getting stuck with interop issues =/

xnox@155c66f (feel free to use, or ignore - I believe i have signed CLA for dotnet)

If this is done, I would ideally need backports back to 10, 9 and 8.

But in the mean time will look to see what else I can do on the OpenSSL side of things.

[vcsjones]

@xnox It's likely that OpenSSL 1.1.x support is going to need to stick around for a little bit longer (in fact .NET 10, which isn't even released yet, is the first to drop 1.0.x). So we can't switch entirely to EVP_MAC yet. Dropping OpenSSL 1.x in a backport will never fly, so for any chance of a backport we need to keep existing things working.

We have some complicated shimming and binding capability to make this possible. I can do the work, I just hadn't prioritized it until now. A personal goal for me is to get entirely off of OpenSSL 1.x APIs. There's a lot of good reasons to do this, performance and their eventual removal / deprecation being among them.

I can't speak for back ports, but if you can better explain the user impact, what scenarios are being blocked, etc. it would go a long way to getting a better "Should we backport this?" story.

[xnox]

I can't speak for back ports, but if you can better explain the user impact, what scenarios are being blocked, etc. it would go a long way to getting a better "Should we backport this?" story.

Mostly efforts similar to microsoft/go and elsewhere. At Chainguard, we provide FIPS images of everything and in our implementation of Chainguard FIPS Provider for OpenSSL we only provide approved only algorithms. This makes it very easy to use FIPS and port everything to be FIPS safe - as literary things either work and are all FIPS or fail loudly. Hence our catalog of over 600 FIPS container images is very popular.

We block MD5 and SHA1, because it is very difficult to allow it as digest, yet block it for JWT / HMAC, DRBG, PRNG. And at the same time, both MD5 and SHA1 are actively used as effectively CRC - common example of AWS S3 buckets using MD5 by default as a chunk/final CRC to validate incremental uploads, despite overall using sha256 and strong TLS to actually address contents.

I am looking at opening up access to MD5 and SHA1 digests alone, for CRC purposes, without those digests leaking into any other usage. And despite EVP_* apis correctly blocking things and our FIPS provider refuses to do anything with unapproved digests, a mere addition of the unapproved digests leaks into security sensitive implementations via deprecated APIs.

Hence right now, whilst MD5 in my proposed configuration is allowed as a digest, and blocked for HMAC, in Dotnet, Python and Nodejs they all manage to calculate HMAC-MD5 and thus evading compliance enforcement. (I opened bugs about all of these).

Separately, overall it seems like the preference for OpenSSL 4 is to remove all deprecated APIs see poll results at https://openssl-communities.org/p/SQ80jh2q (scroll Up after opening the page). If when OpenSSL 4 comes out, most people will want to use it, and yet still have working Dotnet Python and Nodejs. So there is that urgency as well.

And yes, making dotnet/runtime compile with no deprecated builds of openssl would be ideal goal.

So very self serving request really. In the meantime, I will seek alternative paths if I can on the openssl side to close policy enforcement leaks via deprecated APIs.