Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <577513DB.60101@jonasschnelli.ch>
Date: Thu, 30 Jun 2016 17:22:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4BDD091-FD80-4EE9-93EF-735B6BBE253C@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>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list


> 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 solution=
 (BIP151 + authentication) requires that a peer trusts that another is not a=
n 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 may
>>> know that he is intercepting the channel?
>>=20
>> It is not clear to me why you believe an attack on privacy by an anonymou=
s 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.

I understand the mechanics of a tunnel between trusting parties that have a s=
ecure side channel. But this assumes that no other peer can connect to these=
 two nodes. How then do they maintain the chain?

The "middle" in this sense does not have to be the wire directly between the=
se two peers. It can be between either of them and any anonymous connection t=
hey (must) allow.

Of course this creates pressure to expand their tunnel. Hence the problem of=
 expanding node identity in an effort to preserve privacy. The protection wi=
ll remain weak until the entire network is "secure". At that point it would n=
ecessarily be a private network.

As Pieter rightly observes, there are and always will be tunnels between tru=
sting nodes. Often these are groups of nodes that are in collaboration, so l=
ogically they are one node from a system security standpoint. But if people b=
ecome generally reliant on good node registration, it will become the regist=
rar who controls access to the network. So my concern rests I this proposal b=
ecoming widely adopted.

> Simple dummy example:
> 1.) Encryption setup with ECDH with ephemeral keys after BIP151
> 2.) Mallory is MITMling the connection. He is substituting both direction w=
ith its own keys
> 3.) Connection is successfully MITMled
> 4.) Alice tells Bob "prove me that you are Bob, please sign the session-ID=
 with your identity key"
> 5.) Bob signs the sessionID (ECDH secret) with his identity key which
> will be unusable for Mallory who has a substituted sessionID in both direc=
tions.
> 6.) Alice has successfully detected the Mallory
>=20
> Disclaimer: 4) and 5) are _not_ authentication proposals :-)
>=20
> </jonas>
>=20