- Where: zoom.us (see Registration below)
- When: January 09 2025, 17:00-18:00 UTC
- Contact:
- Name: Pat Hickey and Bailey Hayes
- Email: pat@moreproductive.org and bailey@cosmonic.com
The meeting is open to CG members only. You can join the CG here.
If this is your first time attending, please fill out the registration form to receive an invite. Please make sure you have joined the CG as above, and that your name appears on the membership page, before registering.
The meeting will be on a zoom.us video conference.
- Opening, welcome and roll call
- Please help add your name to the meeting notes.
- Please help take notes.
- Thanks!
- Announcements
- Submit a PR to add your announcement here
- Proposals and discussions
wasi-tls: Status update and proposal (30 minutes; @dicej, @badeend, @jsturtevant)- Submit a PR to add your announcement here
- Bailey Hayes
- Joel Dice
- Colin Murphy
- Andrew Brown
- James Sturtevant
- Jeff Charles
- Sam Clegg
- Till Schneidereit
- Sehyo Chang
- Timmy Silesmo
- Pat Hickey
- Dan Gohman
- Alex Crichton
- Taylor Thomas
- Dave Bakker
- Luke Wagner
- Piotr Sikora
- Oscar Spencer
- Kate Goldenring
- Michael Warres
- Chris Woods
- Dan Phillips
- Johnny Birch
- Mendy Berger
- Laura Hendrickson
- Sergey Rubanov
- Sean Isom
Slide deck: https://docs.google.com/presentation/d/1ff5qlDn6umWxbldGFzRd3Gnk0K19nB88b0HNS_N3Rfc/edit?usp=sharing
Joel Dice: TLS: Transport Layer Security (not Thread-Local Storage): slides
Joel Dice: About a year ago, I did a sort of pre-proposal to the wasi-sockets collection of interfaces. Now the current thinking based on some experience is to make this a top-level project based on it’s own. Related to wasi-sockets but also able to work independently.
Joel Dice: I will make the case for why wasi-tls is in scope for wasi and complementary to other wasi interfaces.
Joel Dice: wasi:sockets was introduced as part of wasip2. Includes TCP and UDP (client and server), DNS (client), and the goal was to be able to bring existing libraries that require TCP/UDP. The problem is that most of the libraries use TLS which is not supported.
Joel Dice: A few options to address this. Option 1 to compile openssl or other encryption library to Wasm. A lot of application developers do not have the domain knowledge to know whether or not this approach is appropriate for that application, e.g. if timing attacks are relevant for that application. The second option of wasi-crypto is meant for lower-level use cases like building a general purpose crypto library.
Joel Dice: The option that I am proposing is wasi-tls. A high-level API that is TLS specific. There are other benefits besides just usability, like compatibility with kernel TLS and hardware offload. It is harder to misuse.
Joel Dice: Hypothetically a host that supports wasi-crypto but not wasi-tls could use an adapter that could adapt to wasi-tls. wasi-tls is very much compatible with wasi-sockets. wasi-http could be virtualized using wasi-tls and wasi-sockets.
Joel Dice: Dave Bakker drafted an interface based on several conversations across various communities. The interface is out of scope for a phase 1 conversation, we’re getting ahead of ourselves a little bit at this stage let alone an implementation. Dave went through the NodeJS tls API’s and inspected the feasibility of implementing in terms of wasi-tls. James and I also implemented a wasi-tls-based port of .NET’s SSLStream based on a subset of what Dave has designed.
Joel Dice: Proposal is that wasi-tls to move to phase 1.
Colin Murphy: Can you describe more to the relationship between this and wasi-crypto?
Joel Dice: I might not be best equipped to answer this question. I’ve read through the README.md. I believe it’s complementary to wasi-tls.
Colin Murphy: I think it’s based on web-crypto and it would make sense why it wouldn’t interact with tls as you wouldn’t use tls in the browser.
Colin Murphy: What do you need for constant-time for wasi-tls?
Joel Dice: Option 1 doesn’t enter the picture for this proposal because this effectively happens within the host. Hardware acceleration and constant-time ops are the host’s responsibility. I think we’re going to want constant-time ops in the future and I know there was a proposal but it stagnated.
Joel Dice: The .NET implementation works with SQL Server, HTTPS, etc.
Joel Dice: In rust there is the native tls library. In python you have the ssl module. That one is tricky because you have basically a thin wrapper around OpenSSL. I’ve been talking to Brett Cannon and other python folks. There has been a proposal that is sort of higher level that isn’t so tied to OpenSSL directly.
Colin Murphy: What about rustls?
Joel Dice: I don’t know if native tls in rust provides a wrapper. We would have to port native tls to wasi-tls to make this work transparently for end-users.
Chris Woods: I have been looking into exposing hardware acceleration for OpenSSL. My question is about cost of porting. I don’t know if you’ve looked at this, but did you look at doing this with a lower-level way of doing this?
Joel Dice: Yes this is essentially the constant-time ops. Generally the idea would be to replace the assembly codes with calls out to the host so that anything that is constant time sensitive would be handled. Frank was skeptical about this approach being feasible for porting to that approach.
Chris Woods: For folks that were previously using OpenSSL, they would have to replace with something like a shim?
Joel Dice: Yes similar to python. The OpenSSL API is massive with a very callback heavy API. Anything that is relying directly on OpenSSL especially with more esoteric features, it’s going to be a hard push.
Till Schneidereit: Superficially, by porting by compiling to OpenSSL would be the shortest path. As Joel said, all of the constant time ops are done by handwritten assembly. The constant time ops route requires lower-level WebAssembly changes. For a lot of use-cases, you would also need the results of this certified. This would mean an at least three stage process before that approach may become viable. Whereas this takes already certified paths and can use it the moment we declare the implementation as stable.
Colin Murphy: Frank forked OpenSSL and if you had something, you could try that and maybe it would work.
Chris Woods: Performance of this is not good. Wondering if there is a more of a Wasm Core way of doing it.
Till Schneidereit (in chat): we're using OpenSSL compiled to wasm right now
Till Schneidereit (in chat): and no, it's not too slow. You just can't use it for anything crypto sensitive because of the lack of constant-time operations
Colin Murphy: The problem that I’m facing is that we have WebCrypto working because we have a lot of Wasm already working. This is why I am interested in wasi-crypto. This does not takeaway from wasi-tls.
Till Schneidereit (in chat): see: https://github.com/bytecodealliance/StarlingMonkey/blob/main/cmake/openssl.cmake
Joel Dice: There are a lot of use-cases that can be unlocked by wasi-tls. None of this closes the door from alternative approaches.
Mendy Berger: Prob dumb question: Would it be possible to implement wasi-tls on top of wasi-crypto?
Joel Dice: Yes, wasi-tls could be virtualized with wasi-crypto.
Pat Hickey: Let’s hold a unanimous vote. Any dissent?
[consensus declared]
Pat Hickey: This is now a phase 1 proposal.
Andrew Brown: One important piece of feedback that we got in our last presentation was to survey existing users to find who has an intent to deploy to production. Find who will be on the hook to keep this production-worthy. I created a survey and popularized this and spread it through the ml working group. It showed that there is not yet enough public support. There is one group, SecondState, that is public about their support and is using it in production. I believe that we need more public support to satisfy that feedback and really push this towards phase 3. I believe the right thing to do is leave wasi-nn at phase 2 until we have more indication of intent to deploy before moving forward with phase 3.