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
|
Return-Path: <forum@leeclagett.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CFCB74
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 07:23:50 +0000 (UTC)
X-Greylist: delayed 00:05:29 by SQLgrey-1.7.6
Received: from sasl.smtp.pobox.com (pb-smtp0.pobox.com [208.72.237.35])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35E5779
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 07:23:49 +0000 (UTC)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1])
by pb-smtp0.pobox.com (Postfix) with ESMTP id 23C8249B61
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 03:18:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to
:subject:message-id:in-reply-to:references:mime-version
:content-type:content-transfer-encoding; s=sasl; bh=ToxjRig9I5Uv
fN9XIUBFqqoEQQQ=; b=lMfFKTknCn26mKSk2E7NCgN3KxNZnQOTiVOTM/iUx0Ai
N1CjcvrmjgRpwDfZrcgBtgZjbBpocr15k7UkkFcszCgH2JDWyvyYYO15ere9QzI9
K4EhJg7zCOHamkwDTBKelrwqQNcBNWL/AF8PE0ghkOlArjKuX+XAfyrPHYxNhNk=
Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1])
by pb-smtp0.pobox.com (Postfix) with ESMTP id 1CD0149B60
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 03:18:19 -0400 (EDT)
Received: from laptop-m1330 (unknown [173.30.28.99])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pb-smtp0.pobox.com (Postfix) with ESMTPSA id 878CD49B5E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 03:18:18 -0400 (EDT)
Date: Fri, 25 Mar 2016 03:17:29 -0400
From: Lee Clagett <forum@leeclagett.com>
To: Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160325031729.511ab37c@laptop-m1330>
In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch>
References: <56F2B51C.8000105@jonasschnelli.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: BFACA632-F259-11E5-8ED5-E95C6BB36C07-92142693!pb-smtp0.pobox.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Fri, 25 Mar 2016 17:29:32 +0000
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 25 Mar 2016 07:23:50 -0000
On Wed, 23 Mar 2016 16:24:12 +0100
Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
wrote:
> Hi
>
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
>
> Two BIPs that addresses the problem of decoupling wallets/clients from
> nodes while assuming a user (or a group) know the remote peer.
>
> Authentication would be necessary to selective allow bloom filtering
> of transactions, encryption or any other node service that might lead
> to fingerprinting or resource attacks. Authentication would also be a
> pre-requirement for certificate free encryption-handshakes that is
> (enough?) resistant to MITM attacks.
>
> Encryption is highly recommended if you connect a SPV node to a
> trusted node.
>
> Authentication would allow accessing private p2p extensions from a
> remote SPV peer (example: fee estimation).
>
> I'm aware of other methods to increase privacy and integrity (tor,
> VPN, stunnel, etc.), however I think authentication and a basic
> communication encryption should be part of the protocol and its setup
> should be complete hassle-free.
>
> Thanks for your feeback.
>
> /jonas
>
- The motivation sections seem weak. Why not use SSH? It would have
similar setup requirements, and is already a deployed solution. If
there are additional setup simplicities (compared to SSH),
consider listing them. And if one of the motivating factors is
complexity reduction from the various "do everything you could
possible want" protocols/implementations, then add this to the
motivation.
- ECDSA and "ec pubkey" are mentioned, but not the specific curve.
- The hash algorithm for ECDSA is not explicitly mentioned.
- There is no way to change the cryptographic primitives being used or
to update to a new protocol version. Would it be done with a new
message type `auth2` ... ?
- The following seems to be contradictory:
> If the responding peer could not lookup the requesting peer's
> identity-pubkey in the local authorized-peers database or if the
> responding peer could not verify the signature, the requested auth
> message must be ignored to avoid fingerprinting of peers with
> authentication support.
>
> Responding peers must ignore (banning would lead to fingerprinting)
> the requesting peer after 5 unsuccessfully authentication tries to
> avoid resource attacks.
If I connect to a peer, send 5 auth messages followed by another type
of message that gets no response, this could indicate auth support.
Or is this supposed to say ignore further auth messages, but not
other types of messages? The wording seems to suggest an ignore-all.
- The pubkey from the requester is sent in cleartext, which can be used
as an identifier across connections (similar to a MAC, except it can
be seen across every network hop and correlated across connection
types). Hiding this will likely require encryption, and the protocol
will start to look similar to CurveCP. If the additional complexity
is not worth fixing this issue, a section in the encryption BIP
should be added to explain the identifier leakage.
- The known-peers has an IP and port section. Should the requester limit
signatures based on this information? This algorithm or process needs
to be better defined than the vague paragraph about verifying the
integrity of the remote peer; if an implementation uses the
any-one-of server approach the known-peers file becomes more like a
SSL CA list, which does not seem like the intent. However, the example
at the bottom says "Requesting peer does a lookup of (F) in
known-peers database (B)".
- The encryption portion does not mention the pubkey pairs in use for
ECDH (this needs to be described), so I am assuming the pairs from
authentication are re-used. This increases the chances of data
exposure since a single botched k selection (re-use) for ECDSA would
allow for forged authentications, and the decryption of all
historical data. Adding a temporary key exchange would add slight
complexity and one RTT from the requesters perspective, but it
provides forward-secrecy and protection against ECDSA implementation
failures.
- Can the responding peer set a different cipher in the `ecinit`
response, or should/must it be the same?
- What happens if the responding peer does not support the cipher?
Presumably, a rejection?
- The contents of the IV field are unspecified, and should be
specified to contain new output from a CSPRNG for each message.
- Should `enc` messages be wrapped in `auth` messages (presumably so
since there is no MAC)? `encinit` have this restriction, but nothing
is specified for `enc`.
- Is the context hash unique in each direction? There seems to be one,
which would be racy - what if the client wanted to pipeline messages?
Or is the intent a single open request/response style? I think this
_adds_ a restriction to the Bitcoin protocol.
- Instead of a hash, what about a counter in each direction for the
`enc` stream? The auth portion verifies integrity, authenticity, and
completeness of each message (including this counter). Missing
messages (through TCP injection?) would still detected. Using TCP
injection to forcefully teardown a connection is possible in both
designs.
Lee
|
