From aj at erisian.com.au  Mon Oct 19 22:09:09 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Tue, 20 Oct 2015 08:09:09 +1000
Subject: [Lightning-dev] daemon/p2p protocol
In-Reply-To: <CAE8CtV=sfMQ_HU-rtA5V9w6xd-92tKxtQdoJypNHCKa+qZHJqw@mail.gmail.com>
References: <20151016205355.GA18796@navy> <20151019053003.GB19146@navy>
	<CAE8CtV=sfMQ_HU-rtA5V9w6xd-92tKxtQdoJypNHCKa+qZHJqw@mail.gmail.com>
Message-ID: <20151019220909.GB18268@navy>

On Mon, Oct 19, 2015 at 10:51:52AM +0200, Mats Jerratsch wrote:
> Hm interesting. So far the IP-PubKey-Relationship was public for me
> (furthermore, I even think about adding it to the gossip protocol, see
> other post).

Yeah, it's definitely easier to think about that way.

> I think we can mitigate the risks associated fairly well. Suppose
> lightning nodes run on dedicated machines, firewalled against any
> incoming connections (except ones on the lightning port).

(I don't think lightning wallets can realistically run on dedicated
machines/IPs; so that makes a significant distinction between wallets
for consumers and nodes for routing/merchants I think)

> Against MITM and eavesdropping your pubkey to a stranger connecting to
> your node, we can change the protocol such that the one initiating the
> connection always sends his signed pubkey object first.

I don't thnk that works -- if you can MITM Alice and Bob, then you just do
that while they're in the middle of a connection. When Alice reconnects,
she immediately tells you who she is. If Bob tries reconnecting as well,
you find out who he is too. Sending a shared secret nonce instead,
then just sending signatures avoids that; either one can re-establish
the connection if they can actually talk, and if there's a MITM they
reveal nothing, but do discover they can't talk.

Cheers,
aj