WASI: define GSSAPI / TLS / QUIC as socket layer protocols

[npmccallum]

Crypto can never work on top of WASM. So these need to be system APIs.

Red Hat is already working on this. See the effort here: https://github.com/enarx/tlssock

We will be renaming this project shortly to cover the fact that we plan to support TLS, GSSAPI and (hopefully in the future) QUIC.

[maxmcd]

Just curious (not asking with a lot of knowledge), but why can crypto never work on top of WASM?

Is this a "crypto doesn't work in the browser" thing, or a "there is a fundamental issue with the WASM VM" type thing?

[npmccallum]

@maxmcd Cryptography is my day job (Red Hat). WASM is great, but it can never provide guaranteed side-channel protection. We can barely do that on bare-metal with hand-coded assembly. How can we know, at runtime JIT, if the JIT engine only uses constant time and constant cache instructions? Short answer: you can't.

[npmccallum]

@maxmcd I also forgot to mention that there are tons of things like crypto and network offloaders (think: Mellanox). The current situation is that supporting them requires kernel and application-level changes. Putting encrypted transport protocols under the socket layer allows applications to benefit for free.

[maxmcd]

@npmccallum makes so much sense, thanks!

[sunfishcode]

tlssock and the idea of building encrypted transport into existing socket APIs looks very interesting; thanks for the links! Would you be interested in sketching out what a WebAssembly API for that might look like?

In particular, do you think it makes sense to try to make this completely transparent to applications (possibly with the help of libc), or should we be thinking of this more as something that applications would explicitly opt into?

For completeness, there has been some research under the name "CT Wasm" to explore adding features to wasm to support constant-time guarantees. That said, it's reasonable to continue to design APIs that incorporate crypto in the platform.

[npmccallum]

@sunfishcode Absolutely. I plan to be very active in WASI.

TLSSock (soon to be renamed) is still fleshing out the API problem ourselves. But we aren't changing any ABI in Linux.

Transparent encryption is impossible (we know, we tried). Situations like certificate selection will always require application exposure. We also have the problem of relating DNS to name validation. What we can do is make it trivial for apps to support encrypted transports in their existing unencrypted application structure.

"CT Wasm" is not enough. Cryptographers used to worry about constant time. Now we worry much more about constant-cache. This isn't something that WASM can really control.

[sunfishcode]

@npmccallum Wonderful! I'm excited for the possibilities here.

[deian]

Hey sorry to jump on this late.

"CT Wasm" is not enough. Cryptographers used to worry about constant time. Now we worry much more about constant-cache. This isn't something that WASM can really control.

Maybe I am misunderstanding what you mean by constant-cache, but CT-Wasm does prevent cache-based timing attacks by disallowing the use of secret values as indexes into memory.

[npmccallum]

@deian How do you propose to write WASM code that will never branch on any possible compiler with any possible optimizer? Such an implementation can never be FIPS certified.

[deian]

CT-Wasm's type system (which extends Wasm's base type system with secrets) doesn't let you branch on secrets.

Sure, there could be an optimization pass that introduces a branch by undoing bit-arithmetic, but this is something you have to worry about GCC, etc. doing too. The extended type system should make it easy to check the optimization passes though: you should never be introducing branches on things marked secret.

[npmccallum]

@deian It remains to be seen if certification bodies will actually certify this. If they do, they may only certify a combination of WASM compiler in CT-WASM mode + crypto library + native compiler. And the time to certify this will be years and millions of dollars.

Regardless, I think there is significant value in providing a standard API for the crypto network protocols directly. These should be integrated with polling mechanisms, etc.