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.
-------------- 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/107fe9a2/attachment.pgp>

Reply via email to