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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 71B1DA86
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 16:52:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148102.authsmtp.net (outmail148102.authsmtp.net
[62.13.148.102])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6FA5F179
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 16:52:34 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5UGqWIR001719;
Thu, 30 Jun 2016 17:52:32 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5UGqTvo018382
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 30 Jun 2016 17:52:30 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 799814010C;
Thu, 30 Jun 2016 16:50:17 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id A8C3C2056F; Thu, 30 Jun 2016 12:52:27 -0400 (EDT)
Date: Thu, 30 Jun 2016 12:52:27 -0400
From: Peter Todd <pete@petertodd.org>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160630165227.GA5816@fedora-21-dvm>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi"
Content-Disposition: inline
In-Reply-To: <F4BDD091-FD80-4EE9-93EF-735B6BBE253C@voskuil.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 08ff7fef-3ee3-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdQIUEkAaAgsB AmAbWlNeVV97WmI7 bghPaBtcak9QXgdq
T0pMXVMcUQANdl1l QEEeUxFxfwcIeX1z YUIsXngNCkMsIBBg
QRsBFnAHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYA50 eklUcAt6
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Thu, 30 Jun 2016 16:52:35 -0000
--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrot=
e:
>=20
> > On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <dev@jonasschnelli.ch> wrot=
e:
> >=20
> >>>> The core problem posed by BIP151 is a MITM attack. The implied solut=
ion (BIP151 + authentication) requires that a peer trusts that another is n=
ot 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 m=
ay
> >>> know that he is intercepting the channel?
> >>=20
> >> It is not clear to me why you believe an attack on privacy by an anony=
mous 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 =
these two nodes. How then do they maintain the chain?
>=20
> The "middle" in this sense does not have to be the wire directly between =
these two peers. It can be between either of them and any anonymous connect=
ion 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 protectio=
n will remain weak until the entire network is "secure". At that point it w=
ould necessarily be a private network.
>=20
> As Pieter rightly observes, there are and always will be tunnels between =
trusting nodes. Often these are groups of nodes that are in collaboration, =
so logically they are one node from a system security standpoint. But if pe=
ople become generally reliant on good node registration, it will become the=
registrar who controls access to the network. So my concern rests I this p=
roposal becoming widely adopted.
To be clear, are you against Bitcoin Core's tor support?
Because node-to-node connections over tor are encrypted, and make use of on=
ion
addresses, which are self-authenticated in the exact same way as BIP151
proposes. And we're shipping that in production as of 0.12.0, and by default
Tor onion support is enabled and will be automatically setup if you have a
recent version of Tor installed.
Does that "create pressure to expand node identity"?
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJXdU5IAAoJEGOZARBE6K+yGuoH/1gVZU+v0Kq/koTf8Axvs8qV
1hoYa9lg/oBSgS72ZxovtviOmKOWGrO8f9bDueBgLCAyTspKNXR8YynVpMnPAoLh
tBsXFg9CE7IQkAfFpR0uE6xFck49M+zHOOcnXE1hGD5vLdI+zUsclexs2jxvPvJz
SCeZsdQNh0E6dUeG1PjPesy0D9/g8UUqfhuXWox/MqtPmZEk/Td6a28RacCi7EW8
qo5IM/weH16GBKiY4FQA1YpmX8LhMDKpVOcg92TUhkVlkUemnlLTiUyTwCEWuVtz
E42/DJ/teiUg6SgXoHVk9drv9Yufp31ithnf7b/Env6qT7p6VCnua7Zt0KmjgKw=
=yv4n
-----END PGP SIGNATURE-----
--6c2NcOVqGQ03X4Wi--
|
