Upgrade `wasmtime-wasi-tls` implementation to phase 2

[Aditya1404Sal]

Feature

Implement WASI TLS Phase 2 following the simplified security-focused wit proposal from https://github.com/WebAssembly/wasi-tls/issues/13

Benefit

Phase 1 is unstable and only supports client-side TLS. This blocks WASI components from:

• Accepting incoming TLS connections (servers, proxies)
• Accessing connection metadata (cipher suite, peer certificates)
• Following modern async patterns aligned with Preview 2/3

Phase 2 adds server-side support with a simplified, security-first API that:

• Focuses on TLS 1.3 (modern security, 75%+ adoption)
• Removes problematic features (0-RTT replay attacks, suspension points)
• Uses linear async flow that naturally evolves to Preview 3's async/await
• Reduces API surface by ~40% while adding critical functionality

Implementation

Replace current Phase 1 WIT with Phase 2 proposal from https://github.com/WebAssembly/wasi-tls/issues/13

Key additions:

• Server resource with identity/ALPN/client-auth configuration
• Connection resource with cipher-suite, peer-certificate, close methods
• accept() for server-side handshakes
• Async pattern: finish() + subscribe() (Preview 2) -> async finish() (Preview 3)
• Unified rustls/native-tls provider architecture with client/server separation

Security benefits:

• No suspension points = no deadlock/state machine complexity
• TLS 1.3 focus = modern ciphers, forward secrecy
• Linear flow = easier auditing, fewer vulnerabilities

Alternatives

Nonexistent

[Aditya1404Sal]

Note: I'm currently working on a reference implementation for this proposal and will be opening a PR shortly. Creating this issue first to document the feature request and facilitate discussion before the PR review.

[tschneidereit]

I would strongly recommend seeing more of the discussion of the spec change proposal through before implementing this, since I could see things changing substantially. In particular, the last paragraph in Joel's comment on guest language APIs might well result in big changes.

(As an aside, the term "phase" as used here is a bit confusing, as the WASI standardization process uses that term to describe stabilization stages of a proposal. I guess what you're talking about is something like a proposed API change for wasi-tls.)

[Aditya1404Sal]

Thanks for the feedback and clarification on the terminology! You're right, I should've framed this as an "API redesign proposal" rather than "Phase 2." (Apologies for the confusion)

I understand the concern regarding the spec consensus, especially given Joel's comments about guest language API compatibility.

I'll review the existing Research into .NET and NodeJS's APIs to better understand the compatibility requirements.

Are there specific aspects of the API design where prototyping or analysis would be most helpful for moving the discussion forward?

[tschneidereit]

Are there specific aspects of the API design where prototyping or analysis would be most helpful for moving the discussion forward?

At this point I think the discussion is more important than prototyping, honestly

[rvolosatovs]

See https://github.com/WebAssembly/wasi-tls/issues/13#issuecomment-3637161641 for more info, but IMO we should be following the original design from https://github.com/WebAssembly/wasi-sockets/pull/104, probably "refreshed" for p3.

It seems like the order of operations would be something like:

1. Extract a well-scoped part of https://github.com/WebAssembly/wasi-sockets/pull/104
2. "Modernize" it, make it consistent with other wasip3 proposals (e.g. see https://github.com/WebAssembly/wasi-http/tree/7c678c4c10238a4bf4db91a0e27023d680ff65fe/wit-0.3.0-draft)
3. Fill in the incomplete parts / TODOs
4. Open a PR to https://github.com/WebAssembly/wasi-tls
5. (optional) In parallel start working on an implementation for Wasmtime, open a draft PR once ready
6. Once the spec PR is merged - make sure that Wasmtime PR is up-to-date with the latest spec and mark "ready-for-review"
7. Repeat from step 1. as required