TCPLS MP JOIN does not look like a TLS Handshake

[mpiraux]

From a packet capture I took, the client sends a CH with the MP Join extension to which the server directly sends AppData records. Making this look more like a TLS Handshake would require sending a SH along with other obliged accompagnying TLS messages. None of that is currently taken into account in tcpls_accept().

[frochet]

Yes, it is part of list of things "not important for the paper, but important for standardization"

The ClientHello also contains true cryptographic material, which is a waste of CPU. We should feed in the ClientHello and ServerHello random data fast to compute from an existing state. This is especially critical server-side which may receive many TCPLS JOIN handshakes; that's also the reason we do not see any ServerHello response in the current implementation. It is left out because it is performance critical, and it is awaiting a proper implementation (unlike the ClientHello)

[mpiraux]

Actually, from my packet capture also, the ClientHello has already the same random value, so we are kind of half way there.

[frochet]

yeah, it is not intended. Some people are going to cry on the ability for passive observers to link all TCP connections to the same TCPLS sessions. Ideally to prevent that, we need:

• ClientHello/ServerHello fake but random (and easy to compute)
• Re-randomization of TCPLS SessID at each TCPLS Join (i.e., each time it appears in cleartext).

[frochet]

The only thing that bothers me with this, is that it constrains the number of concurrent TCPLS JOIN handshakes we can do. If we have 1 SessID, we can do 1 JOIN at a time.

[mpiraux]

The QUIC solution was to provide many new SessID (called Connection ID) to establish new paths anonymously

[frochet]

Yeah.. but that sucks. We can deterministically derive SessIDs using a fast Cryptographic Hash function here since it is initially received encrypted (unlike QUIC, I think). So we do not need to send multiple SessID like QUIC does.

[mpiraux]

There is a need to control the number of new TCP connections that can be joined at a time I believe also, this mechanism deals with that in addition. Controlling the Connection IDs in QUIC servers allows cooperation with the load balancers I believe also. I would choose to design a simple system for now. The simplest would be to make a full TLS handshake and then replace the secrets once it's done. A slightly more complex one would use those fake but random values. Then an even more complex one would randomizes the Session ID.

I wonder if you are talking about the TLS Session ID or the TCPLS Connection ID, I assumed the later but I think I was wrong, right ? My considerations apply to the choice of the TCPLS Connection ID

[frochet]

I wonder if you are talking about the TLS Session ID or the TCPLS Connection ID, I assumed the later but I think I was wrong, right ? My considerations apply to the choice of the TCPLS Connection ID

Yes, we rebranded it TCPLS Session ID in the full paper (was called Connection ID before, and is still call ConnID in the code :( )

We use the cookie for limiting the TCP connections. But indeed, we could be smarter here.

What about this:

The initial TPCLS handshake respond with an encrypted TCPLS SessID and a integer N announcing the number of potential TCPLS Join the server would accept.

The client sends TCPLS JOIN handshakes with a Cryptographic pseudo-random derivation of the initial SessID:

New_SessID_1 = H(Decrypted(SessID))
New_SessID_2 = H(H(Decrypted(SessID))
...
New_SessID_N = H(...H(Decrypted(SessID))...)

The server also know New_SessID_1 and New_SessID_2 since it regesitered N SessIDs for this TCPLS session doing the same derivation from the ClearText SessID.

This is private, pseudorandom, supports a limit of handhakes, sends only 128 bits on the wire and does not require cookies.

[mpiraux]

I would rather limit the number of active TCP connections joined rather than the number of total joins. Can we adapt it to do so ?

[frochet]

Yeah, I guess. Client and Server need to track a decreasing counter on JOINED TCP connections (set to N on the initial handshake), and update the chain SessIDs as long as this counter is > 0. When the counter reaches 0, N active TCP connections are joined and there is no more valid SessID server-side, so another JOIN should fail, until one of the TCP connection is closed and the counter increased in both peers.

Does that make sense? Implementation specific, we need new events to let the application knows about all these SessIDs, especially when new ones get generated.

[frochet]

Although, because of the birthday paradox, we may need to pump up the size of SessID to 256 bits.

[obonaventure]

If I understand well, the cookie would be replaced by a session id that is generated by a hash chain. what happens if I want to do two joins in parallel ? Say I have two network interfaces, one has failed and I'd like to use the other one with either IPv6 or IPv4. Can I try to initiate the two TCP connections over the second interface with different session ids that are used in parallel ?

[obonaventure]

I would rather limit the number of active TCP connections joined rather than the number of total joins. Can we adapt it to do so ?

This limit would be valid for the entire TCPLS session and imposed by the server ? The main concern is what is an active TCP connection. The client and the server might have a different view on the status of the existing TCP connections. One of them could consider a connection as closed/failed while the other considers it as established. The solution that we propose should take this asymmetry into account. In particular, we should not end up being in a situation where all N connections are assumed to be broken by one host and established by the other