path: root/7d/f5b66b0ac1d727321dd39f909cc1c51e263648

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 76979996
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 23:31:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E629A181
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 23:31:22 +0000 (UTC)
Received: by mail-wm0-f45.google.com with SMTP id a66so48854457wme.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 16:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=3qPHf/R4XaJ3qa62NwEaQo+GsbXdO1Y26Uyw1CSs/rQ=;
	b=unEEFwSMMAdstyhOM/oV8RtLOwNkTBePLLyPxuvUWt3mTuraF8yeTbv6w5cLtzXOpj
	Yty85kYBEYKguQ5/DeiHwVg04GSQkVFVcO+5YX0Q8Oe1Jg6VBzhDphsSA9eIHiF9Lwx2
	aiOSFs9NAc+v+JyhuPKkEGH6kDu3O7omEMZaI4ccp4GxlbIe19gKmtIvf+nDcLrGqUWJ
	cs7MYb27aTsjCg8378qsJztufUE+5AnRFruOsiWGI3hOt3B/t2vwm2p0eqXtQOSem4or
	umhFPhWArSPD20mMRcc5UjyainmsRyUi5xL7Zs/lTfF0Fm4ckOtYyZpyXxrealwSAcmD
	Y78g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=3qPHf/R4XaJ3qa62NwEaQo+GsbXdO1Y26Uyw1CSs/rQ=;
	b=Jrk2jgjQvf1IePz6STn9bZNf0YysUynsE6MqK+V49c4KM4NIM3JL2WtZ/uGjiYknjF
	bVFysflnZGGouI3/Rp3RxyN01030E5F9P1sAkxOEZrXuOmWhDs9IC1VjFiKMRgaphIBJ
	UtfkXOB8M64i+r5tIctwrY2+WHyuSHZrIFe+V4kDjwicsd6WHU8hnMJdnCXW1ktJrO90
	37uLFraMZFpvCPrupiytPmlQKw3AhD0IVL/WuSbmejNDQbb+3ldioQ+kLaI0y8n13mdm
	HPmEYiDZJvoYpdU1kanRxsbXevRf90r5qR5DGGgC/zWt/YlbHzfTKxRXcMlcHFiGTxnv
	rEUw==
X-Gm-Message-State: ALyK8tJ0r146nYOQqTpFGIZEfs9nzmH+C8QWln6pHb1jWAkILE/63IQdSQyiZEIAWUGYHA==
X-Received: by 10.28.191.193 with SMTP id o62mr17339600wmi.64.1467156681219;
	Tue, 28 Jun 2016 16:31:21 -0700 (PDT)
Received: from [10.114.7.71] ([41.33.219.246])
	by smtp.gmail.com with ESMTPSA id bh7sm681951wjb.22.2016.06.28.16.31.20
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 28 Jun 2016 16:31:20 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <5772D8E2.6020007@jonasschnelli.ch>
Date: Wed, 29 Jun 2016 01:31:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A32C431E-A639-40D4-BA2C-BF912D9FEE9D@voskuil.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>
	<5772D8E2.6020007@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 23:31:24 -0000

On Jun 28, 2016, at 10:06 PM, Jonas Schnelli <dev@jonasschnelli.ch> wrote:

>>> In my opinion, the question should be "why would you _not_ encrypt".
>>=20
>> 1) creation of a false sense of security
>=20
> False sense of security is mostly a communication issue.
> BIP151 does focus on encryption (not trust).
>=20
> 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?

The relevant question would be to ask whether encryption would prevent an IS=
P from doing so (which it would not). This is a good example of false sense o=
f security.

> Are node operators aware of the possibilities that ISPs/Data-Centers,
> etc. can hold back peers, etc.?
>=20
> 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.

FWIW I was just answering your question comprehensively. Relationship to BIP=
151 is incidental (though apparently applicable).

Keep in mind my specific concern is not with the design of BIP151, it is wit=
h the implication of its dependency on an unspecified authentication proposa=
l.

>> 2) as a tradeoff against anonymity
>=20
> Can you point out the tradeoffs?
> BIP151 does not introduce fingerprinting possibilities.

The security tradeoff would arise from widespread deployment of authenticati=
on - which is necessary to make encryption useful against envisioned MITM at=
tacks. See my previous discussion of trust zones below.

>> 3) benefit does not justify cost
>=20
> 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.

Simply put, any code that is unnecessary does not justify its cost.

>>> 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 unencrypted=
.
>>=20
>> The question arises from concern over the security of the network in the c=
ase where encryption (and therefore authentication) is pervasive.
>>=20
>> As you point out, anyone can set up a private network of nodes today. The=
se nodes must also connect to the permissionless network to maintain the cha=
in. These nodes constitute a trust zone within Bitcoin. This zone of exclusi=
on operates as a single logical node from the perspective of the Bitcoin sec=
urity model (one entity controls the validation rules for all nodes).
>>=20
>> Widespread application of this model is potentially problematic. It is a n=
on-trivial problem to design a distributed system that requires authenticati=
on but without identity and without central control. In fact this may be mor=
e challenging than Bitcoin itself. Trust on first use (TOFU) does not solve t=
his problem.
>=20
> 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).

TOFU (trust on first use) was a reference to what was discussed on IRC as a p=
otential solution to the (deferred) authentication problem. I didn't mean to=
 imply that it was part of BIP151.

> 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).

This is a restatement of what I have accepted as a premise - that authentica=
tion, and as such, key distribution, will be a necessary part of making any e=
ncryption scheme effective. "Preshared" implies a secure side channel for ke=
y distribution.

> 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 BIP151=
.
> It is  possible to have multiple authentication schemes.

Whether or not there are multiple schemes is not relevant to the point I hav=
e raised. The issue is that authentication is necessary.

>> In my opinion this question has not received sufficient consideration to w=
arrant proceeding with a network encryption scheme (which concerns me as wel=
l, but as I consider it premature I won't comment).
>=20
> 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.
>=20
> BIP151 hopefully has started some brainwork in how encryption and
> authentication could work in Bitcoin and I'm happy to deprecate BIP151 if w=
e have found a better solution or if we come to a point where we agree that B=
IP151 does make the network security worse.

We should contemplate what the distributed permissionless network of anonymo=
us peers looks like once every node authenticates every one of its peers usi=
ng one or more key distribution side channels.

>>> Example: IIRC non of the available SPV wallets can "speak" on of the
>>> possible encryption techniques. Encrypting traffic below the application=

>>> layer is extremely hard to set up for non-experienced users.
>>=20
>> Bloom filters can (and IMO should) be isolated from the P2P protocol. Als=
o, if the proposal creates an insecurity its ease of deployment is moot.
>=20
> If we assume increasing amount of novice users starting with Bitcoin every=
 day, how should these users run wallets without increasing centralization b=
y using webwallets or client/central-server wallets?
> (which is OT, but an interesting question)

I fully appreciate the significant security risk arising from the proliferat=
ion of web wallets. This can only be resolved by people validating using cod=
e under their own control.

Encryption/authentication are orthogonal to this question, assuming people h=
ave wallets directly attached to full nodes. Remoting a wallet from a full n=
ode does not require use of the P2P protocol, and can use encryption/authent=
ication without the concerns I've raised. It properly places the trust bound=
ary around a wallet and its trusted node(s), as opposed to spanning (indepen=
dent) nodes.

>>> On top of that, encryption allows us to drop the SHA256 checksum per p2p=

>>> message which should result in a better performance on the network layer=

>>> once BIP151 is deployed.
>>=20
>> I would not consider this a performance enhancing proposal. Simply droppi=
ng the checksum seems like a better option. But again, it is moot if it crea=
tes 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 dependen=
cy on a future BIP, making BIP151 incomplete without it. I think we can agre=
e that it would be unadvisable to deploy (and therefore to implement) encryp=
tion alone.
>=20
> I think BIP151 does what it says: encryption and laying groundwork for aut=
hentication.
> 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]).

This is an unfair statement. You have acknowledged that BIP151 requires auth=
entication to accomplish its sole objective.

> The missing MITM protection (solvable over auth) is prominent mentioned in=
 the BIP [1].

As I pointed out.

> (from your other mail):
>>> I don't see reasons why BIP151 could weaken the security of the P2P netw=
ork. Can you point out some specific concerns?
>>=20
>> TOFU cannot prevent MITM attacks (the goal of the encryption). Authentica=
tion requires a secure (trusted) side channel by which to distribute public k=
eys. This presents what I consider a significant problem. If widespread, con=
trol over this distribution network would constitute control over who can us=
e Bitcoin.
>> The effort to prevent censorship could actually enable it. I don't think i=
t would get that far. Someone would point this out in the process of vetting=
 the authentication BIP, and the result would be the scrapping of BIP151.
>=20
> I agree that the secure trusted 2nd channel key-sharing problem can be sig=
nificant for large networks and/or connecting to unknown identities.
>=20
> 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 si=
mply physically preshare keys or do it over GPG / Signal App, etc..

Again, it's the fact that authentication is required that produces the issue=
, not that there are multiple ways to implement it.

> And if I have followed the news correctly, there are some clever guys
> working on various internet of trust 2.0 proposals...

I don't see how this is relevant.

>>> BIP151 does not rely on identities. BIP151 does not use persisted keys
>>> (only ephemeral keys).
>>=20
>> BIP 151 is incomplete without authentication.
>=20
> 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.

It seems that we are talking past each other. You haven't yet addressed the i=
ssue that I have raised.

It is the requirement for authentication of any node that any other node may=
 wish to connect to that is the issue. We end up with something that looks l=
ike WoT or PKI. And if not fully controlled by PKI (so using WoT) we will ha=
ve hybrid nodes that accept untrusted connections and propagate information b=
etween trusted and untrusted nodes.

> [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks
>=20