Feature Proposal: s2n_data_connection

[jmayclin]

Background

TLS can be thought of in two phases

• control plane: TLS Handshake/Authentication/Secret Derivtion
• data plane: TLS application data transfer.

I haven't previously thought of things in these terms, but I think a lot of our APIs actually mirror this boundary.

• s2n_free_handshake: moderately cursed API, reflecting the fact that the connection enters a different mode after handshake completion
• s2n handshake buffer freeing: we free the handshake IO buffer after completion -> reflecting the different mode
• s2n connection serialization: anecdotally, this is often used after the handshake. Notably, the connection returned is a "minimal" version which only stores the information required to exchange application data.

Proposal

s2n-tls should vend an s2n_data_connection which is only used for writing/reading application data. This should be implemented entirely in rust.

I imagine this as a fairly low-level primitive which would have the following benefit

• minimal connection footprint: no cert stored on the connection, no associated config, etc
• user-controlled buffering: the s2n_data_connection should allow customers to control the buffering, like the Rustls unbuffered connection.
• make "stapling" connections easier: There is a common usecase where e.g. loadbalancer wants to terminate frontend TLS, and then immediately re-encrypt it to forward it to some backend TLS item. I think we could get some memory usage benefits.

The sloppiest easiest way to implement a prototype would probably be to just steal the stuff from a serialized connection.

[jmayclin]

See some interesting discussion about full/half duplex IO here: https://www.bearssl.org/api1.html#io-buffer

[maddeleine]

Something I wanted to add, s2n-quic currently throws away the s2n-tls connection after using it to perform the TLS handshake (s2n-quic doesn't need it to send/recv encrypted data and the connection is hefty). This caused problems when we added session resumption however, because the session ticket is a post-handshake message, and it's unclear how long you should keep around the s2n_connection so that you can read/send session tickets. If we are deciding to transform the s2n_connection into a minimal struct, I recommend making it able to both send/recv session tickets, so s2n-quic can keep that tiny struct around, instead of the s2n_connection. Just a thought.

[maddeleine]

Okay one more thought, I do think that this project would be very large. Essentially we'd have to duplicate our post-handshake send/recv logic. So that's not a minor task. Maybe we could make it smaller by not allowing any configuration of the IO buffers, since the proposal is that the user owns them. But it is true that we would have to replicate some code for this project.