A way to "extend" the security upgrade when using QUIC by having an additional handshake step

[guyf-starkware]

Description

Hi team,

We use libp2p in our depot. We have a need to add an additional step as part of the security upgrade that will run after Noise/TLS completes (but before the channel upgrade is complete) and will exchange messages over the channel. Very similar scenario to what was described here.

We've gone though the suggested alternatives in the thread and have eliminated the option of creating a new protocol which leaves two options:

1. ConnectionGater
   1. Does not currently exist in the rust implementation.
   2. As I understand it, it does not allow exchanging (additional) messages before reaching a decision so even if it existed in rust it will not fit our needs.
2. Create a custom security upgrade which will run Noise/TLS and upon success will use the channel returned to exchange said messages.
   1. This works and we have implemented this (for TCP)
   2. The issue is that this seems to be incompatible with QUIC, only TCP. It appears that QUIC is tightly coupled with the TLS security upgrade. In the interface we can tune some TLS parameters but we cannot modify/extend it.

Would it be possible to expose an interface through which we can extend TLS when using QUIC to add additional steps post TLS handshake?
We would want to do the following:

• Run TLS. If faild -> fail (same as today)
• If succeeded, give "us" the upgraded channel for us to exchange message on and decide on Success/Fail. (The peer IDs of self and the other node should be available to the extended handshake.)
• If Fail -> fail the security upgrade
• If Success -> return the upgraded channel (same as today)

While we work in Rust we ideally want this to be available in Go too as we partners who use Go.

Thanks!

Motivation

Need to perform an additional handshake after Noise/TLS which involves the peers exchanging messages and use QUIC at the same time.

Requirements

1. Use Quic
2. If TLS succeeds, both sides can use the secure channel created to exchange messages, do some computation, and return Success/Fail. The peer IDs of self and the other node should be available to the extended handshake.
   • If TLS failed the connection is dropped, same as currently.
3. If both sides return Success, the security upgrade completes successful returning the secure channel TLS created (same as today)
4. If one of the sides return fail, the connection is dropped

Open questions

No response

Are you planning to do it yourself in a pull request?

Maybe

[jxs]

Hi, and thanks for the interest :)
anchor a Rust implementation of go-ssv uses request-response to implement a handshake that needs to be fulfilled before all the other behaviors.
From what you describe seems like a similar situation.

[guyf-starkware]

Thanks for the quick response!
If I understand you correctly you're suggesting implementing the additional handshake step as a behaviour right?
I'll dig into anchor code.

Assuming I understand correctly we would prefer to not implement this handshake on the behaviour level but before the connection is marked as ready

[jxs]

If I understand you correctly you're suggesting implementing the additional handshake step as a behaviour right?

no, I suggested using the request-response Behaviour to implement the handshake exchange, sorry I noticed I didn't link the specific file in code, it happens in the handshake mod.

Assuming I understand correctly we would prefer to not implement this handshake on the behaviour level but before the connection is marked as ready

you can use a successful handshake to mark the connection as ready, see here for how anchor reacts to the handshake exchange