path: root/bd/83619add6382876a72f637d30d10ae9d95733d

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 97F2D89F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eric@voskuil.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <dev@jonasschnelli.ch>
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 <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: 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 <dev@jonasschnelli.ch>
To: Eric Voskuil <eric@voskuil.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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--