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 > <[email protected]> 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
Description: OpenPGP digital signature
