summaryrefslogtreecommitdiff
path: root/01/512b7c346957f47d67a4b37cab3cce3fc5ac7e
blob: 3f53759f5f5b7897b2792e93a25c4558913c941e (plain)
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