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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 51060412
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Aug 2016 17:42:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com
[209.85.217.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93AE629F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Aug 2016 17:42:47 +0000 (UTC)
Received: by mail-ua0-f169.google.com with SMTP id 74so79522966uau.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 08 Aug 2016 10:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=kHQGgaEsIFH6BRDVoXKUsTN4OOLrKH9WnvK3xRDQh6w=;
b=hUfLJkp/Sq2KplEOl2rjUOCsEs6UYhl4SfiyduLWITXhpe0EKz8hw5r18ESjBbWfQx
9s+plvJQLuci1VUtwNNNlnCnK8f4LxObqdX2rsLa4Tyn2n0J53GMINfCQ7GHLwatFhd/
IJ8ZZczhYOmu10wviAud2OBBD1/Vb/+vgNVQo4FoHBbLng4s8MucAdQkNvHmLyr/hhwi
omka31oR+JxM+jLU/5v1NL0QHpPmUwwqxOuBWbRUoVeJ02ptrbvQU9afrA3STpztUgAE
W+h0flaV7PWSqGaK39pI+i2AWKrohli10BuCDCBnUgZc/2Zq0/ge5td9IfdLqOjjqGA7
FALw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=kHQGgaEsIFH6BRDVoXKUsTN4OOLrKH9WnvK3xRDQh6w=;
b=OuLrANY94v/XtrXknYdf3bMvMv5Qx30NTbZyEMJccuHQPe8nvQ3vW2++OS6Q6F5f58
/etycKcwCgxAfKaGD4B7TbQ50ByVDV7wVQRaWhgVH6r81fJpDWKuli82ptCrfFQSJt7D
7wQIZEV3yBV0WiX6xbaKm/6pRekhXFTEVoX7fnkBG9DOSBPIbx7wh5RXZf1Q4k6d7AOz
c2qefKzEpgt7Z0jHzgGhK0og0BHeoHDJX54i39wkGe5wUMfC7k8t0c/1EJvrVuBDQBWe
rdg3rzvgfU0x898/iqbVlX70rmez+WdgTqStfJFr5OeB35QwMLbKX4zt92CwKTbxuxnJ
gHLg==
X-Gm-Message-State: AEkoouuC0J6kZ9qyBghydnIbTyQpAF8jKavO7vqKc35O14i7q17VCjA4mLYXKdqjoDPop9q54xo1/DhOUtwPUQ==
X-Received: by 10.31.107.150 with SMTP id k22mr15353098vki.56.1470678166637;
Mon, 08 Aug 2016 10:42:46 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.118.9 with HTTP; Mon, 8 Aug 2016 10:42:45 -0700 (PDT)
In-Reply-To: <57A8BCD9.7050402@AndySchroder.com>
References: <57A89EA3.4020101@jonasschnelli.ch>
<57A8BCD9.7050402@AndySchroder.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Mon, 8 Aug 2016 17:42:45 +0000
X-Google-Sender-Auth: n393CbgiXd-yU505OOgpd_hu5xI
Message-ID: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
To: Andy Schroder <info@andyschroder.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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] 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:42:48 -0000
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 with 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 expect.
> 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 optionally
> 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.
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 stolen and compromised my bitcoin node and placed it on another network under 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.
> 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 it's
> clients are? This would be similar to many of the http based bitcoin block
> 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 about
> who their users are.
Then they're just not listed in the file. The client can ask the server to
authenticate without authenticating itself.
> 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 huge
> 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.
|
