Oh. The key exchange is relevant for CONG in so far that we will also have to do the KX. It does not matter if our transport is libp2p or "GNUnet-Transport".
BR Am Mittwoch, dem 06.11.2024 um 11:37 +0000 schrieb Willow Liquorice: > I was really asking more generally about how the key exchange fits in > with CONG. > > Regards, > Willow Liquorice > > On 06/11/2024 11:32, Martin Schanzenbach wrote: > > Am Mittwoch, dem 06.11.2024 um 11:21 +0000 schrieb Willow > > Liquorice: > > > I am a little surprised that GNUnet's transport layer relies on > > > bidirectional communication between peers. Hypothetical > > > steganographic > > > communicators, or sneakernet connections, may not have that > > > luxury. > > > > Communicators may be uni-directional. But a virtual link that is of > > any > > use for CORE connections MUST have a bi-directional communication > > channel. > > That may go via two different communicators. For example, you may > > have > > a UDP communicator that only allows you to send messages, and an > > incoming communicator via Sattelite (we have no such communicator > > atm) > > the allows you to receive. > > > > IF you can establish a send/receive connection (Think SYN, ACK) via > > any > > communicator combination with a peer, it becomes a "confirmed" > > virtual > > link that is usable for CORE to do a KX and offer this connection > > to > > higher layers. > > > > See also: > > https://docs.gnunet.org/latest/users/subsystems.html#design-goals-of-tng > > > > > > > > How does this fit in with the GNUnet-CONG project to interoperate > > > with > > > libp2p? > > > > I do not know. Is libp2p not always bi-directional? > > > > BR > > Martin > > > > > > > > Regards, > > > Willow Liquorice > > > > > > On 06/11/2024 10:39, Martin Schanzenbach wrote: > > > > Hi, > > > > > > > > I would like to restart the discussion on the ML here again as > > > > I > > > > keep > > > > forgetting what we established and what the way forward is and > > > > I > > > > think > > > > it is better to discuss this "out in the open". > > > > > > > > Our current "PingPong" KX in CORE seems quite odd and complex > > > > to me > > > > and > > > > the requirements fuzzy. > > > > In a nutshell, the protocol tries to establish a DH secret and > > > > it > > > > goes > > > > something like: > > > > > > > > > > > > 0. MyPeerID: Generate an "ephemeral" DH key pair and sign it > > > > with > > > > PeerID private key. Lets call this "cert" > > > > 1. MyPeerID: If MyPeerID > OtherPeerID goto 2; otherwise wait T > > > > time > > > > and then goto 2 > > > > 2. PyPeerID: Send "cert" to OtherPeerID (Ping) > > > > 3. OtherPeerID: Calculates the DH secret from ephemeral public > > > > key > > > > in > > > > "cert" and its own ephemeral DH key (from 0) > > > > 4. OtherPeerID: Confirms handshake by sending message back; > > > > sending > > > > its > > > > own "cert" (Pong). > > > > 5. MyPeerID calculates the DH secret from ephemeral public key > > > > of > > > > OtherPeerID in "cert". > > > > > > > > Now, I have various issues with the protocol: > > > > > > > > a. Freshness: We should use nonces, which we don't and can't > > > > for > > > > reasons including the following > > > > b. Static DH key: The "ephemeral" DH key is actually static > > > > across > > > > handshakes with other peers and across the rekey interval (or > > > > key > > > > validity period, whatever you want to call it). > > > > c. The KX transcript is not signed/verified > > > > d. The roles are not clear. > > > > > > > > Now, the issues seem to stem from the idea that we do not know > > > > which > > > > peer initiates the handshake, so we cannot know which role a > > > > peer > > > > is > > > > in. > > > > In fact, the KX could be initiatet theoretically from both > > > > peers at > > > > the > > > > same time, and we need to take this into account. > > > > Peers determine a KX initiation based on various factors, for > > > > example a > > > > peer may just have learned of the existance of the other peer, > > > > just > > > > started, etc. > > > > This is why the protocol (Steps 0-5) may (within the key > > > > validity > > > > period overlap of both PeerIDs) converge to the same DH secret > > > > regardless of role and KX flow (and yes, this is bad from > > > > security/crypto view). > > > > The state machine to make this happen is implemented, as far as > > > > I > > > > can > > > > see, but I am not sure how well this actually works in practice > > > > given > > > > that we see some erratic behaviour from CORE and regular bug > > > > reports > > > > regarding connectivity (even to the bootstrap peer). > > > > > > > > > > > > Now, I would really like to converge to a semi-standard, known > > > > secure > > > > KX protocol for CORE that has clear requirements and is much > > > > more > > > > streamlined. > > > > As already discussed, I have drafted a KEMTLS-inspired > > > > handshake > > > > here > > > > with 1.5 RTT: > > > > https://docs.gnunet.org/master/developers/apis/cong.html#handshake-protocol-draft > > > > > > > > > > > > I also started to document the current protocol, but it is very > > > > complex > > > > due to its state machine and 3RTT+. > > > > > > > > My Idea: IF we can agree that transport only notifies CORE of a > > > > connection if it can send AND receive messages from that peer > > > > (bi- > > > > directional connectivity, which afair is the case in transport > > > > right > > > > now), I strongly believe that we can simply rely on protocol > > > > Step 1 > > > > that a KX is initiated _at all_. > > > > It can still happen that two KX are initiated one from each > > > > peer at > > > > the > > > > same time. > > > > But in this case, since we assume that we have bi-directional > > > > comms, we > > > > can simply drop the "late" initiator message on one side based > > > > on > > > > the > > > > same condition in Step 1. > > > > > > > > Wdyt? Any comments? > > > > > > > > BR > > > > Martin > > > > > >
