gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CADET protocol: Anna or Betty?


From: Christian Grothoff
Subject: Re: CADET protocol: Anna or Betty?
Date: Sat, 4 Jan 2020 10:34:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 1/3/20 1:35 PM, carlo von lynX wrote:
> Why Anna? Because Alice sounds too much like it's about crypto!
> 
> Greetings from the secushare workshop. We're discussing the
> implications of the protocol design bug regarding that Alice
> (Anna) or Betty logic by which if the channel breaks and
> Betty wants to re-open it, then she can't actually do anything
> because Anna is supposed to start the handshake whereas Anna
> thinks the channel is still up and running and thus doesn't
> do anything.
> 
> We're thinking of introducing an extra message from Betty to
> Anna which tells Anna that Betty would like to be entertained
> and transmits Betty's new channel id. Anna will the either 
> realize she has an old channel id, thus needs to take action,
> or she has *no* channel id, then she probably started negotiation
> at the same time and should act no further (racing condition)
> or she already has that channel id, then also she does nothing.

How would you know which one is the "old" channel ID?

> Does that sound reasonable? Where do we have documentation
> explaining why we have this decision-making logic in the first
> place rather than letting the initiating of the two start the
> handshake? I don't think Tor has anything like that, also TCP
> and TLS don't have it.

That's because those protocols are client-server, which means you have
clear roles. Client initiates, server waits. In a p2p setting, either
party may initiate, and as you point out, even both at the same time.
Hence, we have states that do not ever arise in TCP or TLS.

> Back in the days of PSYC1 I designed it in such a way that if
> both nodes decide to talk to each other at the same time, they
> will interpret each others' initations as the respective 
> responses, resulting in faster link creation.

That cannot suffice, as responding also is used to establish lifeness
(i.e. you are online NOW), and without timestamps (bad idea for
unsynchronized clocks) the only good way to show lifeness is to include
a nonce.  But obviously if both initiate, we cannot include the nonce of
the other peer in the initial message, so we must not interpret mutual
initiation as the response.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]