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
|
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 49C79412
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Aug 2016 17:54:57 +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 84D78276
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Aug 2016 17:54:56 +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 A52052345956D;
Mon, 8 Aug 2016 13:54:55 -0400 (EDT)
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <57A89EA3.4020101@jonasschnelli.ch>
<57A8BCD9.7050402@AndySchroder.com>
<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
From: Andy Schroder <info@AndySchroder.com>
Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B;
url=http://andyschroder.com/static/AndySchroder.asc
Message-ID: <57A8C76D.1080405@AndySchroder.com>
Date: Mon, 8 Aug 2016 13:54:53 -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: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU"
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:54:57 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU
Content-Type: multipart/mixed; boundary="NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3"
From: Andy Schroder <info@AndySchroder.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <57A8C76D.1080405@AndySchroder.com>
Subject: Re: [bitcoin-dev] Authentication BIP
References: <57A89EA3.4020101@jonasschnelli.ch>
<57A8BCD9.7050402@AndySchroder.com>
<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
In-Reply-To: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
--NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 08/08/2016 01:42 PM, Gregory Maxwell wrote:
> On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> I have mixed feelings about strictly tying the identity-public-keys wi=
th a
> [...]
>> guaranteed static IP address. The second reason is because the DNS PTR=
> I don't see any reason that it couldn't also accept a DNS name there.
>
> The purpose of that table is so the client knows which server ID to exp=
ect.
Okay, that may be fine. You are saying otherwise you'd have to do a=20
trial and error and this tying to a network identifier just speeds=20
things up? If the DNS is spoofed, it's no big deal because the=20
authentication will fail anyway?
>
>> I consider it a good thing from a privacy perspective if my IP address=
>> changes every once and a while.
> And the design seeks to preserve that privacy.
>
>> Maybe a strict check option where the identity-public-keys must option=
ally
>> match a specific network identifier would be a compromise? Maybe this =
is up
> The client must know the identity of the server it is expecting. The
> server does not announce itself. If it did then your changing of IPs
> would provide you with no privacy at all.
Good point.
>
> If the design is to provide any protection against MITM you need to
> know who you expected to connect to in any case.
>
>> I think the purpose of this is to detect if someone has physically sto=
len and compromised my bitcoin node and placed it on another network unde=
r control of an attacker.
> Huh. No. Almost the opposite. The system is designed to inhibit
> fingerprinting. You can't tell what identity key(s) a node has unless
> you already know them. This means that if you don't publish your node
> pubkey, no one can use it to track your node around the network.
Cool.
>
>> Is there an option for a wildcard here? Couldn't there be a case where=
the
>> client wants to authenticate, but the bitcoin node does not care who i=
t's
>> clients are? This would be similar to many of the http based bitcoin b=
lock
>> explorer API services that are out there. The API operators have built=
up
>> some reputation, so people use them, but they don't necessarily care a=
bout
>> who their users are.
> Then they're just not listed in the file. The client can ask the server=
to
> authenticate without authenticating itself.
Simple enough.
>
>> Does openssh have this same problem?
> No. OpenSSH doesn't make an effort to protect the privacy of its users.=
>
>> I'm assuming this could be parallelized very easily, so it is not a hu=
ge
>> problem?
> It's not a issue because we're not aware of any usecase where a node
> would have a large list of authenticated peers.
>
>> Each peer can configure one identity-key (ECC, 32 bytes) per listening=
> network interface (IPv4, IPv6, tor).
>
> I'm not aware of any reason for this limitation to exist. A node
> should be able to have as many listening identities as it wants, with
> a similar cost to having a large authorized keys list.
>
So you are saying that you agree with me that the original text needs to =
be revised slightly or I am just misinterpreting the original text?
--NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3--
--nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU
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)
iQEcBAEBAgAGBQJXqMdtAAoJEDT679stRBhrgF4IANCRJ5+ZFZqH84pL9nrBoaxv
5QVoEAKqBSAezm9PMlEqJ1EeP5Nt2B4dU2OcgUy4qqv6xTSCshPHasAZ5THrgpaf
uo1yJwTGx9eLEdAaBPuNxJETqmNLphLYxXrC27lUj5H59HXK9CQ/2+EwOp5P4kin
YkrGJgYdm+gMfu6UvRfs7J/wXL5tipLgIPEEBE3466j23AP5iPpnXY7qn9CbNytI
mPCbp+iLjJYgLAmujonCn/558SwTo2wHIQ5XVAMVOCZQnnlw9Ij1bGrYCGXD34Gw
hjAa1QuwJJ/cajzE3yp9461uQ06LZPbiN0FkD4ylbkim0I0eUfa0zLeuNLJVeDE=
=H9sn
-----END PGP SIGNATURE-----
--nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU--
|
