Matthew Toseland wrote: >> In terms of port scanning, it doesn't make any difference whether the >> users exchange short or long refs. The CPU burden remains on the initiator. > > No. If they get any sort of response at all, they can deduce that there is a > high probability of its being a node.
Right, I understand that port scanning is an issue, but it's independent from the question of whether we use short or long refs. Message 1 of JFKi includes a field called ID_R', "an indication by the initiator to the responder as to what authentication information (e.g., certificates) the latter should use." In other words, the initiator has to show that it knows the responder's identity. If someone scans the port and puts the wrong value in ID_R', the responder is free to ignore the message. Obfuscation raises the bar a bit further: the port scanner has to know the identities of both peers to get a response, because otherwise the message won't decrypt properly and ID_R' will be wrong. > So what we have here then is we prepend the nonce to the phase 0 packet, and > another nonce to the beginning of the phase 1 packet. The rest of the > exchange is then encrypted with H ( nonce + A's pk hash + B's pk hash ). I don't see the need for two nonces - the initiator just prepends a nonce to message 1 (using the terminology from section 2.2 of the JFK paper). The responder tries decrypting the packet with the hash of each of its disconnected peers; if the decryption succeeds (i.e. the ID_R' field has the right value) then it responds with message 2. > - If the attacker knows, or can guess, *BOTH* A and B's pk hashes, he can > decrypt the exchange and prove that one is occurring. Right, and this can be done live or after the fact: if Mallory has a list of intercepted refs and a huge database of, say, AT&T backbone traffic, she can take the first packet in every encrypted flow, assume it starts with a nonce, and try to decrypt the rest of the packet with hash (nonce, ref_1, ref_2) for every pair of refs. So it's by no means secure - it just raises the bar from wholesale filtering/data mining to targetted filtering/data mining using a list of intercepted refs. But obfuscation is cheap, so IMO it's worth raising the bar. > One advantage of long refs is they are big enough to include the ARK, so if > you're already on the network, you can connect later on. Short refs must be > exchanged in real time, while both sides' IPs are valid (or one side if only > one side NATed). Good point. We can get around that by merging the ARK with the long ref: the ARK contains all the information from the long ref as well as the list of addresses, ports, DNS names etc; the whole ARK is exchanged during JFK; the short ref is the address, port and ARK key. You can either use the ARK key to retrieve the ARK from Freenet, or you can do JFK and use the ARK key to validate the ARK exchanged during JFK. > An invite would be almost the same as a short ref, except that the hash > would be a one-time shared secret allowing you to connect once to a (port > forwarded) node. The advantage is you only need to pass them in one > direction, and they can therefore be used comfortably "offline", provided you > have a stable IP and a port forward. The disadvantage is they are more > vulnerable to out-of-band MITM. MITM can be solved by using the shared secret to generate a keypair, then putting the hash of the public key in the invite. During handshaking, the responder must sign both its own identity and the initiator's identity with the corresponding private key. But designing custom protocols is a bad idea... how can we fold this back into JFK? Another issue is whether the advantage of one-way exchange outweighs the danger of people using weak shared secrets such as dictionary words. I'd be more comfortable if each peer generated a separate keypair using a good source of randomness, and both peers exchanged invites. Cheers, Michael
