Re: CORE Key Exchange

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.

How does this fit in with the GNUnet-CONG project to interoperate with 
libp2p?

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