Matthew Toseland wrote:
>> JFK doesn't exactly strike me as a bloated protocol. In fact it was
>> designed to be the simplest possible protocol that would get the job
>> done securely. What did you leave out?
> 
> Only the constants that can be happily implied: the bits we don't need in 
> regular Freenet connections i.e. the pubkeys.

You took out the pubkeys? But without both ends signing their own and
the other's pubkeys, how do you prevent MITM?

> The ARK could be inserted using the node crypto key yes, but I'd really 
> prefer 
> it wasn't, because the pubkey can be read by any node which has the ARK:

That's not quite what I'm suggesting; more like the reverse. The node's
pubkey and all the other information from the current ref are inserted
under the ARK key, and the short ref contains the ARK key. You can
either use it to retrieve the rest of the information from Freenet, or
to verify the information exchanged during JFK.

> Okay, so how do we do this? We need to authenticate in both directions: the 
> client needs to prove it has the invite, and the server needs to prove it is 
> the server.

I think we need to go further than that. Some users will exchange
invites over eavesdroppable channels, so we need mutual authentication:
the client must prove it's the client, not an attacker that's seen the
invite. A two-way exchange of pubkey-based invites is the only way to do
that.

There are lots of channels (phone, IM, email) where an attacker can
easily eavesdrop but can't easily perform real-time MITM, especially if
the invites are hard to spot (ie raw base32 or base64 strings rather
than freenet URLs).

> If we use JFK with I's real pubkey and R's temporary pubkey:
> - If Eve sees the invite, she can decrypt the exchange, and see the pubkeys, 
> but she can't get connected.

She can connect to R by posing as I, because R doesn't know I's
identity. If there's any chance of the invite being seen, we need
two-way invites.

We could offer a choice of one-way or two-way invites, but since users
don't generally know whether they're under surveillance, I don't think
we should leave the choice up to them: we should only offer two-way invites.

> Agreed, with one minor change: JFK uses temporary keys on both sides and 
> exchanges the real ones encrypted once Ke is known. Benefit is that Eve 
> cannot see the pubkeys even if she saw the invite.

Then subsequent handshakes use the long-term keys? Sounds good.

Cheers,
Michael

Reply via email to