[release/7.0-rc1] Remove AES and SubtleCrypto from WASM #74246
Conversation
* Revert 6a02d5d * Revert relevant parts of 4222e69 and AES pieces of 8f75cc9 * Remove Subtle Crypto interop code Fix dotnet#73858
eerhardt
requested review from
radical,
lewing,
pavelsavara and
marek-safar
as code owners
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsBackport of #73858 to release/7.0-rc1 Customer ImpactWe've concluded that using the SharedArrayBuffer approach via a worker is not yielding the end-to-end experience or quality necessary to release this integration. These challenges lead to discussions about how often the managed implementations apply vs. the SubtleCrypto implementations. When we laid out the plan to rely on SubtleCrypto through SharedArrayBuffer, we understood this would enable us to use SubtleCrypto in ~90% of scenarios. The plan was to only fall back to managed implementations "on browsers which do not support SharedArrayBuffer. However, with the recognition that the default end-to-end experience disallows use of SharedArrayBuffer broadly, that changed the picture dramatically. We now find ourselves in the situation where 90% or more of scenarios will be relying on the managed implementations, and customers desiring the native implementations must consider tradeoffs for other behavior changes that will occur in their applications. That's not an acceptable outcome. With these findings and realizations, we're dialing back what we'll be able to support, and we will not rely on a SharedArrayBuffer bridge to invoke async SubtleCrypto APIs from synchronous .NET code. Instead, the supported algorithms will be exclusively supported via managed code and scoped to algorithms without known side channel leaks of the key. Customers needing native implementations or unsupported algorithms such as AES, we advise they use JavaScript interop to invoke SubtleCrypto directly. That approach will allow the application to be written such that the call can be made in an asynchronous context. TestingThe managed implementations of SHA, HMAC, PBKDF2, and HKDF have automated tests in CI. RiskAES encryption was enabled in 7.0-preview7. This is a take-back in functionality for WASM. But given the security implications of using the managed implementation, the risk of breaking WASM apps that worked with 7.0-preview7 is justified. Fix #73858
|
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
lewing
changed the title
|
Approved as it's key to completing a .NET 7 feature, and removing new code we don't want to support. |
|
Approved. |
Backport of #73858 to release/7.0-rc1
Customer Impact
We've concluded that using the SharedArrayBuffer approach via a worker is not yielding the end-to-end experience or quality necessary to release this integration.
These challenges lead to discussions about how often the managed implementations apply vs. the SubtleCrypto implementations. When we laid out the plan to rely on SubtleCrypto through SharedArrayBuffer, we understood this would enable us to use SubtleCrypto in ~90% of scenarios. The plan was to only fall back to managed implementations "on browsers which do not support SharedArrayBuffer. However, with the recognition that the default end-to-end experience disallows use of SharedArrayBuffer broadly, that changed the picture dramatically. We now find ourselves in the situation where 90% or more of scenarios will be relying on the managed implementations, and customers desiring the native implementations must consider tradeoffs for other behavior changes that will occur in their applications. That's not an acceptable outcome.
With these findings and realizations, we're dialing back what we'll be able to support, and we will not rely on a SharedArrayBuffer bridge to invoke async SubtleCrypto APIs from synchronous .NET code. Instead, the supported algorithms will be exclusively supported via managed code and scoped to algorithms without known side channel leaks of the key.
Customers needing native implementations or unsupported algorithms such as AES, we advise they use JavaScript interop to invoke SubtleCrypto directly. That approach will allow the application to be written such that the call can be made in an asynchronous context.
Testing
The managed implementations of SHA, HMAC, PBKDF2, and HKDF have automated tests in CI.
Risk
AES encryption was enabled in 7.0-preview7. This is a take-back in functionality for WASM. But given the security implications of using the managed implementation, the risk of breaking WASM apps that worked with 7.0-preview7 is justified.
Fix #73858