From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D59C9FA for ; Tue, 14 Feb 2017 16:10:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7FF0A12F for ; Tue, 14 Feb 2017 16:10:19 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 691DF2E6010C; Tue, 14 Feb 2017 17:10:18 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1, HTML_MESSAGE autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro.local (unknown [213.55.184.195]) by server3 (Postfix) with ESMTPSA id 9B2A22D00042 for ; Tue, 14 Feb 2017 17:10:16 +0100 (CET) To: Bitcoin Protocol Discussion From: Jonas Schnelli Message-ID: Date: Tue, 14 Feb 2017 17:10:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ib0gmtxC1G9k04AxxDMRxDbKtomkJ7w2M" X-Mailman-Approved-At: Tue, 14 Feb 2017 16:57:31 +0000 Subject: [bitcoin-dev] BIP150/151 concerns and some comments X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:10:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ib0gmtxC1G9k04AxxDMRxDbKtomkJ7w2M Content-Type: multipart/mixed; boundary="9JVgnc7fhCLomCJFrMGOrRlmAOUasm1sO"; protected-headers="v1" From: Jonas Schnelli To: Bitcoin Protocol Discussion Message-ID: Subject: BIP150/151 concerns and some comments --9JVgnc7fhCLomCJFrMGOrRlmAOUasm1sO Content-Type: multipart/alternative; boundary="------------894778AAD6237025B92DF93B" This is a multi-part message in MIME format. --------------894778AAD6237025B92DF93B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Recently I read some concerns about BIP150/151 and its =E2=80=9Eidentity = system=E2=80=9C. I think we should take those concerns seriously and I wrote some comments for some of the concerns I'm aware of. In my opinion, most of these worries are unfounded. Concern 1: BIP150 introduces a identity system that could partition the network #########################################################################= ###### - Users already filtering/authenticate peers by IP tables, =E2=80=9Eaddno= de=E2=80=9C command, peer banning in app-layer. Fast block relay is a good example (example: FIBRE). - BIP150 allows to switch from IP based authentication (which is obviously not ideal) to a secure form of authentication with pre-shared keys (ECDH). - We can=E2=80=99t stop peer operators to selectively manage peers and th= ere are valid reasons to do that Concern 2: But BIP150 makes it simpler and increase the risk of network partitioning #########################################################################= ########### - What is simpler, presharing a pubkey over a secure channel (PGP / Signal) and store in on both peers or calling a =E2=80=9Eaddnode =E2=80= =9C, or =E2=80=9Eiptables-DROP =E2=80=9C? Concern 3: Identity is not something we want in Bitcoin ####################################################### - BIP150 introduces an **optional** authentication over a EC pubkey. The EC pubkey can be changed. It=E2=80=99s different per network interface. Y= ou only reveal it to peers that already have proven the know your identity. - IP addresses are also a form of identity and way more inflexible and different to hide. Concern 4: But peers can fingerprint my node and ban me after BIP150 has been deployed #########################################################################= ############# - They can=E2=80=99t fingerprint you over BIP150 messages, it does not re= veal your identity unless the responding peer has proven he knows your identit= y. Concern 5: BIP150/151 is not necessary, we have already Tor and STunnel, etc. #########################################################################= #### - Tor is an alternative, right. But do we want to depend on those technologies? Using tor for a single secure channel seems like using a sledgehammer to crack a nut. - How many SPV users have encrypted channels to trusted nodes today? Is it accessible for the novice user?=20 - Peer operators who depend on designated connections (with addnode), what security do they have today (IP address, really?)? - I think tor is great, it can be an alternative or an additional security enhancement (encrypt twice). IMO the focus of Tor is not on securing single channels (it's rather onion routing / anonymity). =20 Concern 6: BIP151 gives a false sense of security and has no MITM detecti= on #########################################################################= ## - BIP151 (pure encryption) has no MITM detection, correct. - Without BIP151 encryption, everyone can hook into the stream and read what=E2=80=99s going on. With BIP151, an attacker needs to actively subst= itute ephemeral keys in both direction. This attack is A) more complex to achieve and B) it=E2=80=99s an active attack (no excuse of =E2=80=9EI jus= t made some statistics=E2=80=9C), C) it requires the attacker to accept the risk of b= eing detected. - C) is true because an optional authentication (can be BIP150 or different) would reveal the attack. - Some attacks are worthless if you have to take the risk mentioned in C)= =20 Concern 7: But Bitcoin traffic is trustless, why the hell you want to encrypt it? #########################################################################= ######## - If you use one of the todays available SPV clients, you will reveal your complete wallet content (=E2=80=9E~all your addresses") to every net= work observer between you and the node you have connected to. This means, if you pay for a coffee (while being on the owners WIFI), the coffee owner and all the involved ISPs can correlate your wallet with your other internet behavior. Same is true for your cellphone provider if you use cellular. - They still can, if you don=E2=80=99t have a trusted node, by performing= the attack that involves the risk mentioned in Concern 6. =20 Concern 8: If you want to have a light client, you should use a different channel to communicate with your full node then the p2p layer #########################################################################= ############################################################## - From a design perspective, this could make sense - From an end user=E2=80=99s perspective, this is undesirable (enabled di= fferent port, lack of a (RPC / ZMQ, etc.) standard, no fallback option if the trusted node is down, hard to setup) - Using the p2p channel as the todays SPV do, seems very reasonable to me. Keep the users on the p2p layer! If we don=E2=80=99t want the users o= n that channel, we automatically form a different layer, the wallet-com wild-wes= t. - Keeping the users on the p2p layer also allows future changes where they can help the network in some ways. - Using the p2p layer for a trusted connection also allows to fallback anytime to non-trusted nodes (if your trusted node is no longer reachable). If your SPV peer needs to catch up a couple of hours while your trusted peer was done, fine, download full blocks or change your bloom filters FP rate significant (or sacrifices your privacy in this cas= e). --------------894778AAD6237025B92DF93B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi

Recently I read some concerns about BIP150/151 and its =E2=80=9Eidentity system=E2=80=9C.
I think we should take those concerns seriously and I wrote some comments for some of the concerns I'm aware of. In my opinion, most of these=C2=A0worries=C2=A0are=C2=A0unfounded.


Concern 1: BIP150 introduces a identity system that could partition the network

################################################= ###############################

- Users already filtering/authenticate peers by IP tables, =E2=80=9Eaddnode=E2=80=9C command, peer banning in app-layer. Fast block relay is a good example (example: FIBRE).
- BIP150 allows to switch from IP based authentication (which is obviously not ideal) to a secure form of authentication with pre-shared keys (ECDH).
- We can=E2=80=99t stop peer operators to selectively manage pe= ers and there are valid reasons to do that

Concern 2: But BIP150 makes it simpler and increase the risk of network partitioning

############################################= ########################################

- What is simpler, presharing a pubkey over a secure channel (PGP / Signal) and store in on both peers or calling a =E2=80=9Eaddnode <ip>= =E2=80=9C, or =E2=80=9Eiptables-DROP <ip>=E2=80=9C?

Concern 3: Identity is not something we want in Bitcoin<= /tt>

############################################= ###########

- BIP150 introduces an **optional** authentication over a EC pubkey. The EC pubkey can be changed. It=E2=80=99s different per network inter= face. You only reveal it to peers that already have=C2=A0proven the know your identity.<= br> - IP addresses are also a form of identity and way more inflexible and different to hide.


Concern 4: But peers can fingerprint my node and ban me after BIP150 has been deployed

############################################= ##########################################

- They can=E2=80=99t fingerprint you over BIP150 messages, it d= oes not reveal your identity unless the responding peer has proven he knows your identity.


Concern 5: BIP150/151 is not necessary, we have already Tor and STunnel, etc.

############################################= #################################

- Tor is an alternative, right. But do we want to depend on those technologies? Using tor for a single secure channel seems like using a=C2=A0sledgehammer to crack a = nut.

- How many SPV users have encrypted channels to trusted nodes today? Is it accessible for the novice user?=C2=A0

- Peer operators who depend on designated connections (with addnode), what security do they have today (IP address, really?)?

- I think tor is great, it can be an alternative or an additional security enhancement (encrypt twice). IMO the focus of Tor is not on securing single channels (it's rather onion routing / anonymity).

=C2=A0

Concern 6: BIP151 gives a false sense of security and has no MITM detection

################################################= ###########################

- BIP151 (pure encryption) has no MITM detection, correct.

- Without BIP151 encryption, everyone can hook into the stream and read what=E2=80= =99s going on. With BIP151, an attacker needs to actively substitute ephemeral keys in both direction. This attack is A) more complex to achieve and B) it=E2=80=99s an active attack (no excuse of =E2=80=9EI just made some statistics=E2=80= =9C), C) it requires the attacker to accept the risk of being detected.

- C) is true because an optional authentication (can be BIP150 or different) would reveal the attack.

- Some attacks are worthless if you have to take the risk mentioned in C)

=C2=A0

Concern 7: But Bitcoin traffic is trustless, why the hell you want to encrypt it?

################################################= #################################

- If you use one of the todays available SPV clients, you will reveal your complete wallet content (=E2=80=9E~all your addresses") to every network observ= er between you and the node you have connected to. This means, if you pay for a coffee (while being on the owners WIFI), the coffee owner and all the involved ISPs can correlate your wallet with your other internet behavior. Same is true for your cellphone provider if you use cellular.<= /p>

- They still can, if you don=E2=80=99t have a trusted node, by performing the att= ack that involves the risk mentioned in Concern 6.

=C2=A0

Concern 8: If you want to have a light client, you should use a different channel to communicate with your full node then the p2p layer

################################################= #########################################################################= ##############

- From a design perspective, this could make sense

- From an end user=E2=80=99s perspective, this is undesirable (enabled different port, lack of a (RPC / ZMQ, etc.) standard, no fallback option if the trusted node is down, hard to setup)

- Using the p2p channel as the todays SPV do, seems very reasonable to me. Keep the users on the p2p layer! If we don=E2=80=99t want the users on that chann= el, we automatically form a different layer, the wallet-com wild-west.

- Keeping the users on the p2p layer also allows future changes where they can help the network in some ways.

- Using the p2p layer for a trusted connection also allows to fallback anytime to non-trusted nodes (if your trusted node is no longer reachable). If your SPV peer needs to catch up a couple of hours while your trusted peer was done, fine, download full blocks or change your bloom filters FP rate significant (or sacrifices your privacy in this case).



</jonas>

--------------894778AAD6237025B92DF93B-- --9JVgnc7fhCLomCJFrMGOrRlmAOUasm1sO-- --ib0gmtxC1G9k04AxxDMRxDbKtomkJ7w2M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlijK+cACgkQKdS8tkFv U+wT1w/8D/4fSSIQ8ru7QYoC0tuVcchuxAJ0ZRjGfNbMyKqrgWuxiAHRyAl3GPy9 YVWUgKSHA7hSwlH40vYRSc5iJYUOIcyA2JAsIQu5R+fH5PUJb6Eepv+1u9wYi9Yl r9TlEPkH0U7iN8gZSBKExJyIqYLgs09b3Ou8+ajwZ4FGgQ5gi7fLVyXlt4LTyjYb fHnYM4Ls1IDnUA13FlBAYpZi+aW15r53KanovylZ8hmdLdXWlPndefyyr2LBXT25 JuCBzdmbMUlqH3FSTzzzD3wjQE3p3Re2Ii3xYzqgvbDz6Oo6W5XqxqTYwLApKDUX qIZKVg3iHokhJEy0V6mnnjXiGPOmy4TtbvMu9MG+9sJjzBaiDSgRQOqR+Us4dTzS dcAUyLyiNfhRDpOuT9KqL4WamyxNseyudlO1mQ/p/jq53WlLZUoXrKLW1fq1HFXE OXl/RxkHAkFQkAcfPXiMDs7KwcQd5uelaSvZqWqRzjjyJOhVqRhkiOJUbrhyj2Lr vvv3PCKWdg6C0tGLiAtdeb381vesdU6umWRxn6oFrzoQ6DVpWnYO3rSmrS9spL9w Zvh+fALFtwjUMhVl+zSlKVQNxD17akRRXt7kbOQnizN3ZdxKiMYCmGPPXk9o2POi 0I2F4mKXV0RKREhfQHtBW39eAZpDtt5KyvAV84a3qdEgFJTtcQU= =K3UD -----END PGP SIGNATURE----- --ib0gmtxC1G9k04AxxDMRxDbKtomkJ7w2M--