Re: CORE Key Exchange

[Martin Schanzenbach]

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
>