CORE Key Exchange

Martin Schanzenbach <[email protected]> Wed, 06 Nov 2024 10:39:34 +0000
Newsgroups	gmane.network.gnunet.devel
Message-ID	<[email protected]>
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
signature.asc (application/pgp-signature, 866 B)