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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
|
Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F340AA1E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 22:33:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C5AD5168
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 22:33:39 +0000 (UTC)
Received: by mail-lf0-f49.google.com with SMTP id q132so21164889lfe.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 15:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=k8hocvBlT15dqJj5tUaDAXVyaqvckfp9HzhcOM6R1LM=;
b=hWFxcKnAyRO/IlIg8gpL5fRN2abyn7vaIxypU4A6hj8skBJp+ZEqzpJKgRlQcuNd9l
Z1ThRuoqCt1GVGE5ZAOWZp+3U1my2ZKUfmTyo7scsrgJwcP4rPyNFNIpFszphRlnFqld
cznuU1UEqLkMOwIrMAfQedNbGe+TNWDS6tst7qG25FYblNN/W4XB6EH8uZwBGOn4xnW0
oemmGiWht3tZuq9yxVPITygC/oP/UQuEmrdajnM9Kh5kxrcksR2iyNHi8Epavxle/9P7
XctRMt9+xoVGAUhA4fT6gk4Bto2EtwvwtDRlUyPjMUZ+D7SLcDrcGYMM7g1EDG+xOJAD
bgGw==
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=k8hocvBlT15dqJj5tUaDAXVyaqvckfp9HzhcOM6R1LM=;
b=M33KYnwGS1yzyqzREQM3EeK+tD7qA1rXtGbunAlmMjimLpiw0Wl2mOzURneli+/jhJ
w5FBCzelLjDvQ8xrO/05GtROPog/PHnO0Y76OODiSMwtoaW+iMFS9US0uDrs+pm+nN2Z
xIg0cOqJhox0NxHEdDFlIH3GQroaQ8gAkmM+/nRFKE8kJg4IQ/yfhVq2LyXZGyMPgnpT
2jZJIeYTZazIv6vkPMGbAoo5NrKlczhZwSEWMl7teK5zIp9MXwueZJhWjzmlKfCChwKj
zUYUAcHCx8lTZLRHnRvKey93GTw+vpMom3iCLPZbTDsdDHMoTFziftkXYorGZSkCJ6nl
LtDA==
X-Gm-Message-State: ALyK8tJJh2q5Ew00m+w6unhgzif7Ny82/5LBm/bA0lzm8xkB8Giix9wSJctsNKuhzxtxhg==
X-Received: by 10.25.38.206 with SMTP id m197mr2139325lfm.201.1467153217870;
Tue, 28 Jun 2016 15:33:37 -0700 (PDT)
Received: from [192.168.0.103] (188-115-185-127.broadband.tenet.odessa.ua.
[188.115.185.127])
by smtp.gmail.com with ESMTPSA id 134sm82617ljj.48.2016.06.28.15.33.36
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 28 Jun 2016 15:33:36 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE
Mime-Version: 1.0 (1.0)
From: Cameron Garnham <da2ce7@gmail.com>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <A74C9C1E-07CE-4769-85BA-AA97F55167EC@voskuil.org>
Date: Wed, 29 Jun 2016 01:33:35 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
<20160628182202.GA5519@fedora-21-dvm>
<D40F9E9D-DB6C-4083-A9E8-C5EBC363DB30@voskuil.org>
<20160628201447.GA1148@fedora-21-dvm>
<4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org>
<20160628203605.GA1328@fedora-21-dvm>
<E8335291-7142-4E21-A1E2-76F387426741@voskuil.org>
<CAAS2fgRGbnH-NtPRdLe0yhFSoqJ7b6O25LfyGv_ULHhy8bBSpg@mail.gmail.com>
<B1AF0E38-522E-4EC7-8595-92972D658430@gmail.com>
<A74C9C1E-07CE-4769-85BA-AA97F55167EC@voskuil.org>
To: Eric Voskuil <eric@voskuil.org>
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, 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
X-Mailman-Approved-At: Tue, 28 Jun 2016 22:34:27 +0000
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: Tue, 28 Jun 2016 22:33:41 -0000
--Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
There are two different topics mixed up here.
1. Link-level security (secure connection to the node we intended to connect=
to).
2. Node-level security (aka; don't connect to a 'evil node').
The fist requires link-level encryption and authentication.
The second requires identity authentication.
You described the 'evil node' attack; that indeed needs an identity system t=
o stop. However BIP151 doesn't intend to protect against connecting to evil B=
itcoin Nodes.
It is important not to mixup link-level authentication and node-level authen=
tication.
When your client picks random nodes to connect to, you are not considered wh=
om in particular runs them. (Rather that you have a good random sample of th=
e network).
If you manually add a friends node; at this point you wish to have node-leve=
l authentication. However, this may (and probably should) happen out-of-ban=
d.
Sent from my iPhone
> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
>=20
> Hi Cameron, good to hear from you!
>=20
>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> wrote:
>>=20
>> Unauthenticated link level encryption is wonderful! MITM attacks are over=
rated; as they require an active attacker.
>=20
> This is not really the case with Bitcoin. A MITM attack does not require t=
hat the attacker find a way to inject traffic into the communication between=
nodes. Peers will connect to the attacker directly, or accept connections d=
irectly from it. Such attacks can be easier than even passive attacks.
>=20
>> Stopping passive attacks is the low hanging fruit. This should be taken f=
irst.
>>=20
>> Automated and secure peer authentication in a mesh network is a huge topi=
c. One of the unsolved problems in computer science.
>>=20
>> A simple 'who is that' by asking for the fingerprint of your peers from y=
our other peers is a very simple way to get 'some' authentication. Semi-tru=
sted index nodes also is a low hanging fruit for authentication.
>=20
> It is the implication of widespread authentication that is at issue. Clear=
ly there are ways to implement it using a secure side channels.
>=20
>> However, let's first get unauthenticated encryption. Force the attackers t=
o use active attacks. (That are thousands times more costly to couduct).
>>=20
>> Sent from my iPhone
>>=20
>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>>>=20
>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> An "out of band key check" is not part of BIP151.
>>>=20
>>> It has a session ID for this purpose.
>>>=20
>>>> It requires a secure channel and is authentication. So BIP151 doesn't p=
rovide the tools to detect an attack, that requires authentication. A genera=
l requirement for authentication is the issue I have raised.
>>>=20
>>> One might wonder how you ever use a Bitcoin address, or even why we
>>> might guess these emails from "you" aren't actually coming from the
>>> NSA.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><br></div><div id=3D"AppleMailSignatur=
e">There are two different topics mixed up here.</div><div id=3D"AppleMailSi=
gnature"><br></div><div id=3D"AppleMailSignature">1. Link-level security (se=
cure connection to the node we intended to connect to).</div><div id=3D"Appl=
eMailSignature"><br></div><div id=3D"AppleMailSignature">2. Node-level secur=
ity (aka; don't connect to a 'evil node').</div><div id=3D"AppleMailSignatur=
e"><br></div><div id=3D"AppleMailSignature">The fist requires link-level enc=
ryption and authentication.</div><div id=3D"AppleMailSignature"><br></div><d=
iv id=3D"AppleMailSignature">The second requires identity authentication.</d=
iv><div id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSignature">Y=
ou described the 'evil node' attack; that indeed needs an identity system to=
stop. However BIP151 doesn't intend to protect against connecting to evil B=
itcoin Nodes.</div><div id=3D"AppleMailSignature"><br></div><div id=3D"Apple=
MailSignature">It is important not to mixup link-level authentication and no=
de-level authentication.</div><div id=3D"AppleMailSignature"><br></div><div i=
d=3D"AppleMailSignature">When your client picks random nodes to connect to, y=
ou are not considered whom in particular runs them. (Rather that you have a g=
ood random sample of the network).</div><div id=3D"AppleMailSignature"><br><=
/div><div id=3D"AppleMailSignature">If you manually add a friends node; at t=
his point you wish to have node-level authentication. However, this ma=
y (and probably should) happen out-of-band.</div><div id=3D"AppleMailSignatu=
re"><br></div><div id=3D"AppleMailSignature"><br>Sent from my iPhone</div><d=
iv><br>On 29 Jun 2016, at 01:07, Eric Voskuil <<a href=3D"mailto:eric@vos=
kuil.org">eric@voskuil.org</a>> wrote:<br><br></div><blockquote type=3D"c=
ite"><div><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"><div><span></span></div><div><meta http-equiv=3D"content-type" conten=
t=3D"text/html; charset=3Dutf-8"><div></div><div><span style=3D"background-c=
olor: rgba(255, 255, 255, 0);">Hi Cameron, good to hear from you!</span></di=
v><div><br>On Jun 28, 2016, at 11:40 PM, Cameron Garnham <<a href=3D"mail=
to:da2ce7@gmail.com">da2ce7@gmail.com</a>> wrote:<br><br></div><blockquot=
e type=3D"cite"><div><meta http-equiv=3D"content-type" content=3D"text/html;=
charset=3Dutf-8"><div><span style=3D"background-color: rgba(255, 255, 255, 0=
);">Unauthenticated link level encryption is wonderful! MITM attacks are ove=
rrated; as they require an active attacker.</span></div></div></blockquote><=
div><br></div><div>This is not really the case with Bitcoin. A MITM attack d=
oes not require that the attacker find a way to inject traffic into the comm=
unication between nodes. Peers will connect to the attacker directly, or acc=
ept connections directly from it. Such attacks can be easier than even passi=
ve attacks.</div><br><blockquote type=3D"cite"><div><div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);">Stopping passive attacks is the l=
ow hanging fruit. This should be taken first.</span></div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span styl=
e=3D"background-color: rgba(255, 255, 255, 0);">Automated and secure peer au=
thentication in a mesh network is a huge topic. One of the unsolved problems=
in computer science.</span></div><div><span style=3D"background-color: rgba=
(255, 255, 255, 0);"><br></span><div><div><span style=3D"background-color: r=
gba(255, 255, 255, 0);">A simple 'who is that' by asking for the finger=
print of your peers from your other peers is a very simple way to get 'some'=
authentication. Semi-trusted index nodes also is a low hanging fruit f=
or authentication.</span></div></div></div></div></div></blockquote><div><br=
></div><div>It is the implication of widespread authentication that is at is=
sue. Clearly there are ways to implement it using a secure side channels.</d=
iv><br><blockquote type=3D"cite"><div><div><div><div><span style=3D"backgrou=
nd-color: rgba(255, 255, 255, 0);">However, let's first get u<font>nauthenti=
cated encryption. Force the attackers to use active attacks. (That are thous=
ands times more costly to couduct).</font></span></div></div><br>Sent from m=
y iPhone</div><div><br>On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin=
-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote type=3D"=
cite"><div><span>On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-d=
ev</span><br><span><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</span><br><blockquo=
te type=3D"cite"><span>An "out of band key check" is not part of BIP151.</sp=
an><br></blockquote><span></span><br><span>It has a session ID for this purp=
ose.</span><br><span></span><br><blockquote type=3D"cite"><span>It requires a=
secure channel and is authentication. So BIP151 doesn't provide the tools t=
o detect an attack, that requires authentication. A general requirement for a=
uthentication is the issue I have raised.</span><br></blockquote><span></spa=
n><br><span>One might wonder how you ever use a Bitcoin address, or even why=
we</span><br><span>might guess these emails from "you" aren't actually comi=
ng from the</span><br><span>NSA.</span><br><span>___________________________=
____________________</span><br><span>bitcoin-dev mailing list</span><br><spa=
n><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></blockquo=
te></div></div></blockquote></body></html>=
--Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE--
|
