- Its sans-I/O design. Too many networking-related libraries out there mix the protocol state machine logic and the I/O. In doing so, they impose a certain style of I/O and make it impossible to integrate with an existing event loop, unless you’re willing to sacrifice scalability by spawning a thread+semaphore for each connection. I’d love it if I could use libssh2 or libmysqlclient’s state machine with io_uring or DPDK! Other TLS libraries do have stuff like memory BIOs, but they’re managed by the library and force an extra memory copy to get your data to its final destination.
- No mutable global state. The fact that all functions are fully reentrant means that it’s easily usable in an interruptible context, common in freestanding environments or runtimes with fibers/coroutines.
The tradeoff is that it lacks TLS 1.3 and DTLS support. The latter in particular is something I look forward to so that a QUIC state machine in C is possible.
TLS 1.3 isn't mentioned.
Also, Bear is unlikely to do e.g. 0-RTT which might be a TLS 1.3 feature you really wanted unless you just "want it so badly" because it's a bigger number.
TLS has always been weak to a few classes of attacks (historically both MITM and replay attacks), but these developers are taking that weakness very seriously. Also, most HTTP requests are idempotent, which is going to be the use case of 99% of people.
The other two reasons they give are about abstractions that they defined for themselves. The idea of buffering 0-RTT requests is also kind of silly, and completely untenable if you want to avoid memory waste.
"We're good, everyone. Justine is on it."