1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2921DA97
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 18:25:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3226711D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 18:25:49 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id r201so130706014wme.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 11:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=9/QalzsQk548Z6ibdcOLSizLBUGXNo7fyhUzlyNenoo=;
b=aICYIsBlr9x6sTNIsRe/rLJP81w+Azpaieo/1MpNglYP3mJah9XrMQkou+9AdYQ83h
mYSJgorpU+8J+Xtk3ILnA53Wz1ZTJbrQgOI+oQfDPCAnVinejFMfolef6/52+sRUviP7
aIIWcfCSBWQbK7RvhM3eDc7oTi+VhwrQM2Zk+z5jmR3jg2B4ldAqUvxVUsc/iZFlga3t
xykPPccPTDGbgaWAoJ+4htSlJlD7iNikYGnpARpadrKzlqs5Ufrk7dOjemdR5rhCRiW6
fIUNTEnPhEQS1kGdN8Da3yd6+L/bzG8nK7bbSl48ortzaaUtH8V1Lgpw++b39o+q4SXA
sGwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=9/QalzsQk548Z6ibdcOLSizLBUGXNo7fyhUzlyNenoo=;
b=FXYjkT9QH9URVfybyD42tUa0A4YViSdP3EMUTxxmw7KICje6O9p1E0Z2GnGFjcUjCr
mXfdGZbEshZZnIDBMlTPjHCu16B868GIafmQ6rlNUXiuU9f4T6FYUifTF+wzlsWUGT2Q
8htjVhzqfFI6E87dtiyoS77Kanjc9VJII3BshfvPC6FyKchKa7rJe0KpJw9oADdYXu1b
J2OkbdjhOv5J+niNQyjfcuw6M2riY8JT3wKrQop2pyuf5k5O2m2H3H4nJ/afnr6sGEFR
lCSO9NzGc4Hqrf2LO3sn1MYGVHER3e5dGDHuYJQpi7HnETx6x/4KSWzpChqmDx3ycDDG
3ffQ==
X-Gm-Message-State: ALyK8tISfwiyMQea4pJudQvNCXNPXbjDQdw/da1MYgl/2pE3e3IbQs/lnDksM2MAYnw83g==
X-Received: by 10.194.88.5 with SMTP id bc5mr16474295wjb.100.1467311147594;
Thu, 30 Jun 2016 11:25:47 -0700 (PDT)
Received: from [197.161.189.105] ([197.161.189.105])
by smtp.gmail.com with ESMTPSA id
jf3sm4733101wjb.41.2016.06.30.11.25.46
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 30 Jun 2016 11:25:46 -0700 (PDT)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (13F69)
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>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 18:25:50 -0000
> 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=
|
