[WASI] Options for implementing wasi-tls proposal

[jsturtevant]

There is a proposal for adding tls support in wasi-sockets. After adding socket support it makes sense to enable more scenarios with were tls is required. One instance would be using SqlClient.

We've done a few prototypes to figure out how this might work with dotnet:

• The first was an implementation using the public API but done out of tree. We used that to prove we could use it with minimal changes to SqlClient.

• The second is where I attempted to use the existing SSLStream design and PAL layer with the wasi-tls interfaces. I was able to get it to successfully work but found several issues with the approach.

In the second approach there is a mismatch between the level of the wasi-tls design and the existing SslStream implementation. wasi-tls operates on a transparent stream delegating the handling to the Host. In dotnet's SslStream implementation, the SslStream class handles all of the I/O, tls frame processing, and sends the frames one by one to the SSL context. Since we don't have that level of the SSL context exposed via the wasi-tls interface, and all the processing is happening asynchronously on the host side there is an issue of knowing when all the content has been sent to the host a fully processed by the SSL context and sent back to the guest to be forwarded on the socket layer.

I can think of a few of options to move forward (maybe more if I am missing something, which I might be):

1. Make changes to the wasi-tls interface to expose a different type of interface that would support the current approach in dotnet's SslStream class. The downside to this is that thee wasi-tls interface is simple and easy to understand as designed today. It keeps the details out of the guest implementation and lets the host handle the complexity.
2. Create a special case in the SslStream library for WASI that by-passes the current PAL abstraction around SSL and fills in the parts that make sense for wasi-tls in the public API. This would be somewhat similar to the first prototype implementation and be similar to httphandler.
3. Refactor parts of the current PAL SSL abstraction to support this SSL stream. Downside is that all of the PAL layer is sync and we also still have the challenge of know when we've sent enough information to the underlying SSL context to get a response back.

Looking for some feedback on the various approaches.

/cc @pavelsavara @dicej

[dotnet-policy-service]

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

[dicej]

I'm in favor of Option 2 since it allows us to keep wasi:sockets/tls high-level, giving us more flexibility to implement it efficiently and securely in the common case where the host is also managing the I/O. That saves us from having to pipe both the ciphertext and the plaintext across the guest/host boundary, leaving the details of framing and (re)handshaking to the host.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

I also prefer option 2 but I would like to hear more about the gaps.
Which C# APIs are not possible or difficult to implement ?
Does SSLStream on Andoid have similar limitations ?

I suggest that we have conf call about it in week of 17/11

[jsturtevant]

I've started to work on option 2 and will report back once I have something to look at