We have 3 connection modes: 1. Darknet - including new connections established as part of opennet after a completed request.
Encrypted using both sides' keys, so full privacy is available. For reasons explained below, we should use JFKi. 2. Bootstrap - new node reads a list of seednodes, connects to several nodes (can't be NATed), each of them sends an announcement for it within the darknet which eventually results in a list of nodes connecting to the newbie. Encrypted using the responder's key. Initiator knows the responder. 3. Invite - i give you a file which contains my reference and a time-limited access code that allows you to connect one node. Similar to bootstrap but only works with proof of knowledge of the access code. E.g. on the first stage, I -> R, we add a requirement for H ( "invite" + access code ), and on the second and third we add a challenge/response protocol. On Thu, Mar 22, 2007 at 08:36:14PM +0000, Matthew Toseland wrote: > Interesting proposal. > > Two key elements that make the use case and attacks somewhat different > to what was expected by the authors of JFK: > - On a darknet, each side already knows the other node's public key. > (Although there is also opennet, and one-time invitations, to > consider). > - Darknet: There is an outer layer of encryption based on both nodes' > setup keys, which will protect us from eavesdropping in any event, > unless the attacker already has both references in which case we have > no privacy in any case. > - On an opennet, or possibly some invite protocols, we would encrypt > using only the receiver's setup key. But still, the initiator MUST > know the identity of the receiver in advance in any case. > > Hence we are really much closer to the client/server model than the p2p > model for purposes of JFK: We do not need to protect the identity of the > receiver from either active or passive attacks. > > JFKr prevents eavesdropping (not a problem for us), it prevents active > identity discovery of the responder. JFKi on the other hand prevents > active identity discovery of the initiator, which is a plausible if > limited attack on Freenet: Get the node's reference, take over its IP > address, watch for incoming connect attempts, you get IP + pubkey. > With JFKi, you will still get incoming connect attempts, but they do not > include a pubkey. > > The RFC says: > > "The second variant of the JFK protocol provides the same DoS > protection and identity protection against passive attackers for > both the Initiator and the Responder, but no protection against > active identity discovery attacks for the Initiator (the Responder > is protected against active identity discovery)." > > Translation: If you take over a node's IP, you can identify connecting > nodes, although you can't connect to them. > > One thing JFKr does have going for it is the lack of non-repudiable > signatures (you can't prove that two nodes connected, even if you have > their noderefs). But I'm not convinced how much this will help. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070322/bcface9e/attachment.pgp>
