Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <20160630165227.GA5816@fedora-21-dvm>
Date: Thu, 30 Jun 2016 20:25:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <663B51FE-D8D5-4570-ACA6-D1405D98C773@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
	<20160629111728.GO13338@dosf1.alfie.wtf>
	<2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>
	<57750EAB.3020105@jonasschnelli.ch>
	<426C2AA3-BFB8-4C41-B4DF-4D6CC11988B2@voskuil.org>
	<577513DB.60101@jonasschnelli.ch>
	<F4BDD091-FD80-4EE9-93EF-735B6BBE253C@voskuil.org>
	<20160630165227.GA5816@fedora-21-dvm>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list


> On Jun 30, 2016, at 6:52 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
>> On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wr=
ote:
>>=20
>>> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <dev@jonasschnelli.ch> wrote=
:
>>>=20
>>>>>> The core problem posed by BIP151 is a MITM attack. The implied soluti=
on (BIP151 + authentication) requires that a peer trusts that another is not=
 an attacker.
>>>>>=20
>>>>> BIP151 would increase the risks for MITM attackers.
>>>>> What are the benefits for Mallory of he can't be sure Alice and Bob ma=
y
>>>>> know that he is intercepting the channel?
>>>>=20
>>>> It is not clear to me why you believe an attack on privacy by an anonym=
ous peer is detectable.
>>>=20
>>> If Mallory has substituted the ephemeral keys in both directions, at the=

>>> point where Alice and Bob will do an authentication, they can be sure
>>> Mallory is listening.
>>=20
>> I understand the mechanics of a tunnel between trusting parties that have=
 a secure side channel. But this assumes that no other peer can connect to t=
hese two nodes. How then do they maintain the chain?
>>=20
>> The "middle" in this sense does not have to be the wire directly between t=
hese two peers. It can be between either of them and any anonymous connectio=
n they (must) allow.
>>=20
>> Of course this creates pressure to expand their tunnel. Hence the problem=
 of expanding node identity in an effort to preserve privacy. The protection=
 will remain weak until the entire network is "secure". At that point it wou=
ld necessarily be a private network.
>>=20
>> As Pieter rightly observes, there are and always will be tunnels between t=
rusting nodes. Often these are groups of nodes that are in collaboration, so=
 logically they are one node from a system security standpoint. But if peopl=
e become generally reliant on good node registration, it will become the reg=
istrar who controls access to the network. So my concern rests I this propos=
al becoming widely adopted.
>=20
> To be clear, are you against Bitcoin Core's tor support?
>=20
> Because node-to-node connections over tor are encrypted, and make use of o=
nion
> addresses, which are self-authenticated in the exact same way as BIP151 pr=
oposes.

BIP151 is self-admittedly insufficient to protect against a MITM attack. It p=
roposes node identity to close this hole (future BIP required). The yet-to-b=
e-specified requirement for node identity is the basis of my primary concern=
. This is not self-authentication.

> And we're shipping that in production as of 0.12.0, and by default Tor oni=
on support is enabled and will be automatically setup if you have a recent v=
ersion of Tor installed.
>=20
> Does that "create pressure to expand node identity"?

The orthogonal question of whether Tor is safe for use with the Bitcoin P2P p=
rotocol is a matter of existing research.

e=