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
|
Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 39ADDA55
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jun 2016 00:06:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com
[209.85.214.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9119319B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jun 2016 00:06:42 +0000 (UTC)
Received: by mail-ob0-f177.google.com with SMTP id xn17so3474945obc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 17:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=2VFw/RsuoZpzBdOaOuI6B4TJTnfWyju9pz4L8cnk3wI=;
b=hZvs430K30QdE7X55udG4AaVimNQZf/B8B4slbd7dwoKZlWHAstDcC8MVLSCotLvw9
EnF92TSaE+jQn1uci18SDaA2cS+h4sz2AX3MBYcz2Oxgg4iUupkHuAxlGzSjwvBTLI/h
JCqfSvRq1vjQIF96GRa9FUfI7d0nn+bfje/f4JXRc3wyaYFaaS8ZgfyZYvwv8m6SqtiK
eEWNYnTz+LMZZeqxDrWUyPOYqh0afXSfs9AoF3G6FybAhzrAxhvM7J9ZTye52Mqch7E4
T66thexDQjAABp1csvFT25nhlpcvDa5QjhAnpGqN0MwFj23CRxHgbHKyDnsSDYzk2SKB
6BQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=2VFw/RsuoZpzBdOaOuI6B4TJTnfWyju9pz4L8cnk3wI=;
b=YLfWIfMU9drTufAvyNw+hXjhfQE6RUs+J5SBr5lHhU+YGdIAYDMfHdwGTtQc60z41L
eu9jlTs2vRSGZNhWaWPODPTx3eZQ0DsgeKXnDPI2mo5+j3oWJP5KYSKLBeUnRCJk0Mh9
PnKhZrRS/Z85Gr5L9MrQn3LwrMhWeyz/BMIoqo4vv2PG78YAB20+M63/31eYAfT4vFSv
tlNqe9NBmsD0PwsqBZE8LJ550woaNjP3JeaYKP7jT6qfN1HV+DiIt9rVVVUvNgHuFQMK
p9rDpg9uETRXUDGjKP1HZ3cGjY4DbO3zDwNNgCRKErF7+UxpmkIM+suSSTGMa9h+D8EE
z8ig==
X-Gm-Message-State: ALyK8tJeq6vRQTYhSx1EIGMFJRU0KUhHgQXdOjopVgBQVa78Ab3Q7zlxfiLNUjXqFAFSKCk40V77ncaH+4T6kg==
X-Received: by 10.157.1.107 with SMTP id 98mr3851170otu.17.1467158801795; Tue,
28 Jun 2016 17:06:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.217.106 with HTTP; Tue, 28 Jun 2016 17:06:41 -0700 (PDT)
In-Reply-To: <2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@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>
<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>
<E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>
<2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@voskuil.org>
From: Nick ODell <nickodell@gmail.com>
Date: Tue, 28 Jun 2016 18:06:41 -0600
Message-ID: <CANN4kmfqbWwPhD1kyWMsrRhDJaniu3f3Ca_-LSuNawDwY1_uvw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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
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: Wed, 29 Jun 2016 00:06:43 -0000
>They both require authentication,
Yeah, but not the same *sort* of authentication. As a trivial example,
you could have ten servers that sign long-term keys for nodes. All
that they need to check is that the node requesting a signature owns
the corresponding IP address. On the other hand, 'evil nodes' is a
subjective quality that is hard to assess automatically.
>and if you intend to connect to potentially evil nodes you aren't securing anything
Bitcoin is designed with the assumption that some of the nodes you
connect to might be evil. Sure, if 100% of the nodes you're connected
to are evil, you're screwed. However, we shouldn't avoid protecting
people from someone on the same coffee-shop network, just because the
same mitigation won't work against a nation-state.
On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Your description of the two scenarios reduces to one. They both require
> authentication, and if you intend to connect to potentially evil nodes you
> aren't securing anything with link level security except the knowledge that
> your potentially evil node connection remains so.
>
> e
>
> On Jun 29, 2016, at 12:33 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
>
>
> 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
> to stop. However BIP151 doesn't intend to protect against connecting to evil
> Bitcoin Nodes.
>
> It is important not to mixup link-level authentication and node-level
> authentication.
>
> When your client picks random nodes to connect to, you are not considered
> whom in particular runs them. (Rather that you have a good random sample of
> the network).
>
> If you manually add a friends node; at this point you wish to have
> node-level authentication. However, this may (and probably should) happen
> out-of-band.
>
>
> Sent from my iPhone
>
> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
>
> Hi Cameron, good to hear from you!
>
> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> wrote:
>
> Unauthenticated link level encryption is wonderful! MITM attacks are
> overrated; as they require an active attacker.
>
>
> This is not really the case with Bitcoin. A MITM attack does not require
> that the attacker find a way to inject traffic into the communication
> between nodes. Peers will connect to the attacker directly, or accept
> connections directly from it. Such attacks can be easier than even passive
> attacks.
>
> Stopping passive attacks is the low hanging fruit. This should be taken
> first.
>
> Automated and secure peer authentication in a mesh network is a huge topic.
> One of the unsolved problems in computer science.
>
> A simple 'who is that' by asking for the fingerprint 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 for authentication.
>
>
> It is the implication of widespread authentication that is at issue. Clearly
> there are ways to implement it using a secure side channels.
>
> However, let's first get unauthenticated encryption. Force the attackers to
> use active attacks. (That are thousands times more costly to couduct).
>
> Sent from my iPhone
>
> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>
>
> It has a session ID for this purpose.
>
> It requires a secure channel and is authentication. So BIP151 doesn't
> provide the tools to detect an attack, that requires authentication. A
> general requirement for authentication is the issue I have raised.
>
>
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
