|
On 04.01.2020 10:37, Christian Grothoff wrote:
On 1/3/20 3:23 PM, carlo von lynX wrote:
On Fri, Jan 03, 2020 at 10:28:02PM +0900, Schanzenbach, Martin wrote:
On 3. Jan 2020, at 21:35, carlo von lynX <address@hidden> 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
That sounds like it allows anyone to highjack any (established) channel
after a successful kx.
Oh, transport does not guarantee the identity of nodes so CADET
has to handle authentication itself... great. Still, an attacker
would not be able to hijack a conversation, just break it.. right?
Transport guarantees it for hop-by-hop, but CADET is end-to-end. So
Transport may assure Anna that she's talking to xrs, and to xrs that
he's talking with Betty, but that doesn't help us for Anna-Betty.
A concern here is an attacker replying an ancient initiation message to
break an ongoing session.
Given that we have 3DH, this should only be about availability, not
confidentiality/integrity.
Is it sufficient to add a payload signed with the public key of Anna
(the peer id not an ego!)?
dvn has suggested a different approach, to make the
CADET_CONNECTION_CREATE ensure that both sides have the same
state, so we are looking into adding extra info there (which
I understand would be a breaking protocol change, since gnunet
does not have PSYC's extensibility).
Breaking compatibility to fix these types of bugs is OK.
Even with this approach we then need to add the above mentioned
payload, for Betty to check if the right peer is requesting a new
handshake.
|
signature.asc