Re: CORE Key Exchange

[Martin Schanzenbach]

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
> > > 
> > 
>