Re: CORE Key Exchange

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