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
|
Return-Path: <info@AndySchroder.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F3D62412
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Aug 2016 17:09:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from uschroder.com (uschroder.com [74.142.93.202])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id A699F270
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Aug 2016 17:09:49 +0000 (UTC)
Received: from [192.168.253.4] (cpe-96-28-21-149.kya.res.rr.com [96.28.21.149])
by uschroder.com (Postfix) with ESMTPSA id 6AA842345936B;
Mon, 8 Aug 2016 13:09:48 -0400 (EDT)
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <57A89EA3.4020101@jonasschnelli.ch>
From: Andy Schroder <info@AndySchroder.com>
Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B;
url=http://andyschroder.com/static/AndySchroder.asc
Message-ID: <57A8BCD9.7050402@AndySchroder.com>
Date: Mon, 8 Aug 2016 13:09:45 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Authentication BIP
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: Mon, 08 Aug 2016 17:09:51 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8
Content-Type: multipart/mixed; boundary="Cx5JA03uek1dMBS2UTJ6VRfVCad5BN8k5"
From: Andy Schroder <info@AndySchroder.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57A8BCD9.7050402@AndySchroder.com>
Subject: Re: Authentication BIP
References: <57A89EA3.4020101@jonasschnelli.ch>
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>
--Cx5JA03uek1dMBS2UTJ6VRfVCad5BN8k5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a=
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.
I have mixed feelings about strictly tying the identity-public-keys with =
a network identifier. I think the purpose of this is to detect if=20
someone has physically stolen and compromised my bitcoin node and placed =
it on another network under control of an attacker. This seems to be a=20
bit of a benefit, however, an attacker could always spoof the original=20
network identifier anyway.
I run my bitcoin node on an internet connection that does not guarantee=20
a static IP address (although it usually stays the same for several=20
weeks or months at a time). I'd like to be able to make secure=20
connections back to my own node, even if I know the IP address may=20
change from time to time. There are several reasons for wanting to this=20
with a changing IP. The first is because the bandwidth on my internet=20
connection with a guaranteed static IP address is considerably more=20
expensive than my internet connection without a guaranteed static IP=20
address. The second reason is because the DNS PTR record for my static=20
IP address is personally identifiable based on other reasons/services.=20
The internet connection that my bitcoin node is using without a=20
guaranteed static IP address just has a PTR record that basically=20
includes my IP address and ISP name. This isn't much use to the general=20
public (although my ISP obviously knows who I am). The third reason is=20
that I consider it a good thing from a privacy perspective if my IP=20
address changes every once and a while.
Maybe a strict check option where the identity-public-keys must=20
optionally match a specific network identifier would be a compromise?=20
Maybe this is up to the client implementation to decide, so it should=20
just be suggested in the BIP rather than required?
> # ___authorized-peers___ contains authorized identity-public-keys
Is there an option for a wildcard here? Couldn't there be a case where=20
the client wants to authenticate, but the bitcoin node does not care who =
it's clients are? This would be similar to many of the http based=20
bitcoin block explorer API services that are out there. The API=20
operators have built up some reputation, so people use them, but they=20
don't necessarily care about who their users are.
> =3D=3D=3D Local identity key management =3D=3D=3D
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
What if I have bitcoind listening on multiple IPv4 interfaces? Can I=20
have a different identity-key for each IPv4 interface?
Also, would it be possible to only allow this authentication on specific =
interfaces? In my example above where I have two internet connections,=20
if you don't agree to loosening the tie between the network identifier=20
and the identity-public-keys, maybe I would just connect my bitcoin node =
to both internet connections, but only allow a few authorized-peers on=20
the static IP (which would be low bandwidth), and then not authenticate=20
on the internet connection with the changing IP at all
If you don't want to increase complexity by adding these options, one=20
could always accomplish the same thing by runing two instances of=20
bitcoind and pairing the two over a local network, it would just be a=20
waste of resources.
> =3D=3D Disadvantages =3D=3D
>
> The protocol may be slow if a peer has a large authorized-peers databas=
e
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.
Does openssh have this same problem?
I'm assuming this could be parallelized very easily, so it is not a huge =
problem?
--Cx5JA03uek1dMBS2UTJ6VRfVCad5BN8k5--
--mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJXqLzZAAoJEDT679stRBhrd8sH+gLi50vb/nY4p4QRtoSHt9Q1
oJs7epIYM1/CAiEht5JhfSSSQDd8b7qlx1pShu9wgzTODqq2VR+Thz3MD1f2BIkW
KUHUL+xikIaBsXITRKxhRqpu/etm4/MZiJJKJ+KukCvMsY5R5e4CszTs5Zgadd7V
HRrdMy9aOWOcmBwr31DU1t0yE3XssUm1sRQ8YWxsrr928oxvVyilev4+rXGCdsEl
OKDCWc03MH4EYqhNemezb0fYekpdIHbqgyWAapbdHGlW6onUFWioIC4Cgh/3Chln
SzvHXjqoQo9YPoR3n0BhexBV+490O/r6OBZvJz9rLnGppjdf0RzEtqIWRqqzrac=
=K+i4
-----END PGP SIGNATURE-----
--mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8--
|
