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 97F2D89F for ; Tue, 28 Jun 2016 20:07:05 +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 804AF1AF for ; Tue, 28 Jun 2016 20:07:04 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 9E2CA2E604A5; Tue, 28 Jun 2016 22:07:03 +0200 (CEST) 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 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro-2.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id AFEB72D000CB; Tue, 28 Jun 2016 22:07:02 +0200 (CEST) To: Eric Voskuil , Bitcoin Protocol Discussion References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> From: Jonas Schnelli Message-ID: <5772D8E2.6020007@jonasschnelli.ch> Date: Tue, 28 Jun 2016 22:06:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vdu8Gp78Ef08524wt1utaCafNub8r0LGS" Subject: Re: [bitcoin-dev] BIP 151 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, 28 Jun 2016 20:07:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vdu8Gp78Ef08524wt1utaCafNub8r0LGS Content-Type: multipart/mixed; boundary="j3ujfhn1Sc8KVmIB6hbm3DkQuI7qGRbaB" From: Jonas Schnelli To: Eric Voskuil , Bitcoin Protocol Discussion Message-ID: <5772D8E2.6020007@jonasschnelli.ch> Subject: Re: [bitcoin-dev] BIP 151 References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> In-Reply-To: <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org> --j3ujfhn1Sc8KVmIB6hbm3DkQuI7qGRbaB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >> In my opinion, the question should be "why would you _not_ encrypt". >=20 > 1) creation of a false sense of security False sense of security is mostly a communication issue. BIP151 does focus on encryption (not trust). Are users aware of the fact that ISP/WiFi-Providers can track their bitcoin spending (if they use SPV+BF) and link it with other internet traffic or sell the data to anyone who is interested to do correlation? Are node operators aware of the possibilities that ISPs/Data-Centers, etc. can hold back peers, etc.? If there is a false sense of security/anonymity, then we are already deep into this territory. BIP151 was designed as a puzzle-pice towards better security and better censorship resistance. You shouldn't project all sorts of "false sense of security" into BIP151. Is a stepping stone towards greater security. > 2) as a tradeoff against anonymity Can you point out the tradeoffs? BIP151 does not introduce fingerprinting possibilities. > 3) benefit does not justify cost Can you elaborate the costs? [Extremely simplified]: we need 300 lines of code from openssh (ChaCha20-Poly1305@openssl) and some ECDH magic (already in Bitcoin-Cores codebase) together with two or three (maybe payed) cryptoanalysis once the implementation is done. >> There are plenty of other options to solve this problem. stunnel, >> Bernsteins CurveCP, VPN, etc. which are available since years. >> But the reality has shown that most bitcoin traffic is still unencrypt= ed. >=20 > The question arises from concern over the security of the network in th= e case where encryption (and therefore authentication) is pervasive. >=20 > As you point out, anyone can set up a private network of nodes today. T= hese nodes must also connect to the permissionless network to maintain th= e chain. These nodes constitute a trust zone within Bitcoin. This zone of= exclusion operates as a single logical node from the perspective of the = Bitcoin security model (one entity controls the validation rules for all = nodes). >=20 > Widespread application of this model is potentially problematic. It is = a non-trivial problem to design a distributed system that requires authen= tication but without identity and without central control. In fact this m= ay be more challenging than Bitcoin itself. Trust on first use (TOFU) doe= s not solve this problem. Yes. There is no plan to adopt a TUFO scheme. Bip151 does not use TUFO it does not cover "trust" (It just encrypt all traffic). Imaging Bip151 together with a simple form of preshared EC key authentication (nonce signing or similar). You could drastically increase the security/censor-resistance-properties between nodes where owners have preshared identity keys (with nodes I also mean SPV/wallet nodes). And I guess there are plenty of awesome identity management system ideas tied or not tied to the Bitcoin blockchain out there. This is also a reason to not cover trust/authentication/identity in BIP15= 1. It is possible to have multiple authentication schemes. > In my opinion this question has not received sufficient consideration t= o warrant proceeding with a network encryption scheme (which concerns me = as well, but as I consider it premature I won't comment). Yes. I think nobody have started implementing BIP151. It's a draft BIP and I think it's still okay and great that we have this discussion. BIP151 hopefully has started some brainwork in how encryption and authentication could work in Bitcoin and I'm happy to deprecate BIP151 if we have found a better solution or if we come to a point where we agree that BIP151 does make the network security worse. >> Example: IIRC non of the available SPV wallets can "speak" on of the >> possible encryption techniques. Encrypting traffic below the applicati= on >> layer is extremely hard to set up for non-experienced users. >=20 > Bloom filters can (and IMO should) be isolated from the P2P protocol. A= lso, if the proposal creates an insecurity its ease of deployment is moot= =2E If we assume increasing amount of novice users starting with Bitcoin every day, how should these users run wallets without increasing centralization by using webwallets or client/central-server wallets? (which is OT, but an interesting question) >> On top of that, encryption allows us to drop the SHA256 checksum per p= 2p >> message which should result in a better performance on the network lay= er >> once BIP151 is deployed. >=20 > I would not consider this a performance enhancing proposal. Simply drop= ping the checksum seems like a better option. But again, it is moot if it= creates an insecurity. >=20 >> I agree that BIP151 _must_ be deployed together with an authentication= >> scheme (I'm working on that) to protect again MITM during encryption >> initialization. >=20 > At a minimum I would propose that you modify BIP151 to declare a depend= ency on a future BIP, making BIP151 incomplete without it. I think we can= agree that it would be unadvisable to deploy (and therefore to implement= ) encryption alone. I think BIP151 does what it says: encryption and laying groundwork for authentication. You wouldn't probably say BIP32 is incomplete because it does not cover a scheme how to recover funds (or BIP141 [SW consensus] is incomplete because it does not cover p2p [BIP144]). The missing MITM protection (solvable over auth) is prominent mentioned in the BIP [1]. (from your other mail): >> I don't see reasons why BIP151 could weaken the security of the P2P ne= twork. Can you point out some specific concerns? >=20 > TOFU cannot prevent MITM attacks (the goal of the encryption). Authenti= cation requires a secure (trusted) side channel by which to distribute pu= blic keys. This presents what I consider a significant problem. If widesp= read, control over this distribution network would constitute control ove= r who can use Bitcoin. > The effort to prevent censorship could actually enable it. I don't thin= k it would get that far. Someone would point this out in the process of v= etting the authentication BIP, and the result would be the scrapping of B= IP151. I agree that the secure trusted 2nd channel key-sharing problem can be significant for large networks and/or connecting to unknown identities. But as said, there could be multiple ways of sharing identity keys. If you want to connect your node to serval other trusted nodes, you can simply physically preshare keys or do it over GPG / Signal App, etc.. And if I have followed the news correctly, there are some clever guys working on various internet of trust 2.0 proposals... >> >> BIP151 does not rely on identities. BIP151 does not use persisted keys= >> (only ephemeral keys). >=20 > BIP 151 is incomplete without authentication. I would agree if you would say, _trusted encryption_ is incomplete with authentication. But IMO BIP151 is complete and should be deployed together with one or multiple authentication schemes. [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks --j3ujfhn1Sc8KVmIB6hbm3DkQuI7qGRbaB-- --vdu8Gp78Ef08524wt1utaCafNub8r0LGS 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 iQIcBAEBCAAGBQJXctjjAAoJECnUvLZBb1PsacsP/i9UAlEauJo0d5AjFfQjvW/k lRgYm8s1ZJP2m19DftJsKn9WRrobri7R5gMRbsS451oqo53vMel3KWIVuXJfi3nu UGSPro3O8BfSbUP0wbB3gokGh4yr/heCVLNUVlu77xMiWGLmL8M/pBlAd5gprE/6 e8SQNqdfTEFsPsfEMGPFVv8iyrgKA+OqKE53xJaZjevsXb4RxDtQZEuL2lyBz4EA ndNE58tyKqBe0hT1FGhF47GUgZABcMmK//ZvZd9/2JsVpH4gWRRgTKCH0AJ6bWcJ WAReoNdlcjplYPcjVxXT0iSy4XVjHbHme6uGFmcNyyuA78y/D4B7c4xW1Ui4GFIf WNNBTcZtYVxJ4lzb3sr8WnPR/6zaYJZxbkZiugqhPNXInyhcgwufhVGGXT4LeDdN 13daCGJ8U/UYpv/I2+iLz7u5YNsc+CMbA7VUZYNFKOyShf0pqz3EXrO17C/0VkkF AzA1EdsLgQ+EqDVF1QcB+aoMtUOsncTP1dV8D6ZjR8ABjFMwDG+locJu3lyymkDB GoEQJvgID2QoqVAHJeBbWneHay+5S1xc4+Hs98ua6iyjQMEgoHfl1DVlpq4dihtm hspACqnl2URtB/Re/3+Eb275sA9ViE7PxnDxsCxhoMmCXBVAIgsrO/NLnHasMZZm QYKX05qV6AVb4mYRHnMQ =/9UE -----END PGP SIGNATURE----- --vdu8Gp78Ef08524wt1utaCafNub8r0LGS--