path: root/1a/2005123e0f7690321d1dadc65c6fddb1900824

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 4896625A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 23:29:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2289D161
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 23:29:14 +0000 (UTC)
Received: by mail-wm0-f42.google.com with SMTP id r201so48790406wme.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jun 2016 16:29:14 -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=mPCdFHxrCDANReFHY6W8kO5R123VqGnattmNH1k1gBo=;
	b=DnMlr5S39vAZfcka3F+nhQxafq3zwTEK2dJZbW76ztp0Dv16XkwWuG8xGpcHyHesRM
	AiVjj7kxU1WVj11aVccqsqgJO6J9mGF/pV4basx8cax/fVbaMKhd0IXw52qqBY8pb/P4
	Y+jQziRTtwLQiQJsaCHlrFkusicozyXDr2KA+gPz28XwYbLGs9DgY9J1RWs06YTX00HT
	5uHkhpFFKRRWa0yzhh2CVyRbcP1S57rjS48ZqZdtGLUAE1Qs2tZ4zaY94e2OaJ4SN9+o
	YPwgUR7d82mvN83jKrz9e9IYO4G24Tpx7lZ0bxFyUhF2T0kvOY6rYc3BAu3S6l4TYrF0
	kcUA==
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=mPCdFHxrCDANReFHY6W8kO5R123VqGnattmNH1k1gBo=;
	b=BtZJR9jlYqs1kkssLIae+mHRLrEyQOB8ajhjTnA7gk+xsb8PzlGbU5vSpZm0JmseOC
	kxURkkn5nb2JcGExyTkGHQDQDvsmjZKhWZErtFq0xSVWWQDRE8V64pDn8qi64gzbJvBx
	OPxhQKmR7ZhJ8lat0Wokf2R7tXDrLjS0YYNiVugiX2v21uRG3ZJsmHFFMSdDCIIG7isB
	RfW1Zwq50dNNhvWeZjaNKUEjfvL0CROCdJ8HOjmRnSFFkbmqXXxIskSM9W1nQuaUDqCT
	kapN/6ZhgR90HaKaJZOJk8mwkWxuPVL76Q14pesWUtRY+YoGPMzKCK254KFnqEicrsjo
	sq+Q==
X-Gm-Message-State: ALyK8tIzANdUeZfOB/NiynY/IcQAPwB6b6q2Icvi4SL84DPoxy5rSnKOiGQr5/0QyXjnNw==
X-Received: by 10.28.86.214 with SMTP id k205mr17387929wmb.17.1467156552723;
	Tue, 28 Jun 2016 16:29:12 -0700 (PDT)
Received: from [10.114.7.71] ([41.33.219.246])
	by smtp.gmail.com with ESMTPSA id ue1sm643722wjc.44.2016.06.28.16.29.11
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Tue, 28 Jun 2016 16:29:11 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-18BE1868-157C-4975-AEC1-642652226EEC
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>
Date: Wed, 29 Jun 2016 01:29:10 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@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>
	<20160628182202.GA5519@fedora-21-dvm>
	<D40F9E9D-DB6C-4083-A9E8-C5EBC363DB30@voskuil.org>
	<20160628201447.GA1148@fedora-21-dvm>
	<4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org>
	<20160628203605.GA1328@fedora-21-dvm>
	<E8335291-7142-4E21-A1E2-76F387426741@voskuil.org>
	<CAAS2fgRGbnH-NtPRdLe0yhFSoqJ7b6O25LfyGv_ULHhy8bBSpg@mail.gmail.com>
	<B1AF0E38-522E-4EC7-8595-92972D658430@gmail.com>
	<A74C9C1E-07CE-4769-85BA-AA97F55167EC@voskuil.org>
	<E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>
To: Cameron Garnham <da2ce7@gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, 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:29:15 -0000


--Apple-Mail-18BE1868-157C-4975-AEC1-642652226EEC
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Your description of the two scenarios reduces to one. They both require auth=
entication, and if you intend to connect to potentially evil nodes you aren'=
t securing anything with link level security except the knowledge that your p=
otentially evil node connection remains so.

e

> On Jun 29, 2016, at 12:33 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
>=20
>=20
> There are two different topics mixed up here.
>=20
> 1. Link-level security (secure connection to the node we intended to conne=
ct to).
>=20
> 2. Node-level security (aka; don't connect to a 'evil node').
>=20
> The fist requires link-level encryption and authentication.
>=20
> The second requires identity authentication.
>=20
> You described the 'evil node' attack; that indeed needs an identity system=
 to stop. However BIP151 doesn't intend to protect against connecting to evi=
l Bitcoin Nodes.
>=20
> It is important not to mixup link-level authentication and node-level auth=
entication.
>=20
> When your client picks random nodes to connect to, you are not considered w=
hom in particular runs them. (Rather that you have a good random sample of t=
he network).
>=20
> If you manually add a friends node; at this point you wish to have node-le=
vel authentication.  However, this may (and probably should) happen out-of-b=
and.
>=20
>=20
> Sent from my iPhone
>=20
>> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
>>=20
>> Hi Cameron, good to hear from you!
>>=20
>>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> wrote:
>>>=20
>>> Unauthenticated link level encryption is wonderful! MITM attacks are ove=
rrated; as they require an active attacker.
>>=20
>> This is not really the case with Bitcoin. A MITM attack does not require t=
hat the attacker find a way to inject traffic into the communication between=
 nodes. Peers will connect to the attacker directly, or accept connections d=
irectly from it. Such attacks can be easier than even passive attacks.
>>=20
>>> Stopping passive attacks is the low hanging fruit. This should be taken f=
irst.
>>>=20
>>> Automated and secure peer authentication in a mesh network is a huge top=
ic. One of the unsolved problems in computer science.
>>>=20
>>> A simple 'who is that' by asking for the fingerprint of your peers from y=
our other peers is a very simple way to get 'some' authentication.  Semi-tru=
sted index nodes also is a low hanging fruit for authentication.
>>=20
>> It is the implication of widespread authentication that is at issue. Clea=
rly there are ways to implement it using a secure side channels.
>>=20
>>> However, let's first get unauthenticated encryption. Force the attackers=
 to use active attacks. (That are thousands times more costly to couduct).
>>>=20
>>> Sent from my iPhone
>>>=20
>>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>>>>=20
>>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>> An "out of band key check" is not part of BIP151.
>>>>=20
>>>> It has a session ID for this purpose.
>>>>=20
>>>>> It requires a secure channel and is authentication. So BIP151 doesn't p=
rovide the tools to detect an attack, that requires authentication. A genera=
l requirement for authentication is the issue I have raised.
>>>>=20
>>>> One might wonder how you ever use a Bitcoin address, or even why we
>>>> might guess these emails from "you" aren't actually coming from the
>>>> NSA.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-18BE1868-157C-4975-AEC1-642652226EEC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>Your description of the two=
 scenarios reduces to one. They both require authentication, and if you inte=
nd to connect to potentially evil nodes you aren't securing anything with li=
nk level security except the knowledge that your potentially evil node conne=
ction remains so.</div><div><br></div><div>e</div><div><br>On Jun 29, 2016, a=
t 12:33 AM, Cameron Garnham &lt;<a href=3D"mailto:da2ce7@gmail.com">da2ce7@g=
mail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><meta ht=
tp-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div><br></=
div><div id=3D"AppleMailSignature">There are two different topics mixed up h=
ere.</div><div id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSigna=
ture">1. Link-level security (secure connection to the node we intended to c=
onnect to).</div><div id=3D"AppleMailSignature"><br></div><div id=3D"AppleMa=
ilSignature">2. Node-level security (aka; don't connect to a 'evil node').</=
div><div id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSignature">=
The fist requires link-level encryption and authentication.</div><div id=3D"=
AppleMailSignature"><br></div><div id=3D"AppleMailSignature">The second requ=
ires identity authentication.</div><div id=3D"AppleMailSignature"><br></div>=
<div id=3D"AppleMailSignature">You described the 'evil node' attack; that in=
deed needs an identity system to stop. However BIP151 doesn't intend to prot=
ect against connecting to evil Bitcoin Nodes.</div><div id=3D"AppleMailSigna=
ture"><br></div><div id=3D"AppleMailSignature">It is important not to mixup l=
ink-level authentication and node-level authentication.</div><div id=3D"Appl=
eMailSignature"><br></div><div id=3D"AppleMailSignature">When your client pi=
cks random nodes to connect to, you are not considered whom in particular ru=
ns them. (Rather that you have a good random sample of the network).</div><d=
iv id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSignature">If you=
 manually add a friends node; at this point you wish to have node-level auth=
entication. &nbsp;However, this may (and probably should) happen out-of-band=
.</div><div id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSignatur=
e"><br>Sent from my iPhone</div><div><br>On 29 Jun 2016, at 01:07, Eric Vosk=
uil &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt; wrote:<=
br><br></div><blockquote type=3D"cite"><div><meta http-equiv=3D"content-type=
" content=3D"text/html; charset=3Dutf-8"><div><span></span></div><div><meta h=
ttp-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div></div=
><div><span style=3D"background-color: rgba(255, 255, 255, 0);">Hi Cameron, g=
ood to hear from you!</span></div><div><br>On Jun 28, 2016, at 11:40 PM, Cam=
eron Garnham &lt;<a href=3D"mailto:da2ce7@gmail.com">da2ce7@gmail.com</a>&gt=
; wrote:<br><br></div><blockquote type=3D"cite"><div><meta http-equiv=3D"con=
tent-type" content=3D"text/html; charset=3Dutf-8"><div><span style=3D"backgr=
ound-color: rgba(255, 255, 255, 0);">Unauthenticated link level encryption i=
s wonderful! MITM attacks are overrated; as they require an active attacker.=
</span></div></div></blockquote><div><br></div><div>This is not really the c=
ase with Bitcoin. A MITM attack does not require that the attacker find a wa=
y to inject traffic into the communication between nodes. Peers will connect=
 to the attacker directly, or accept connections directly from it. Such atta=
cks can be easier than even passive attacks.</div><br><blockquote type=3D"ci=
te"><div><div><div><span style=3D"background-color: rgba(255, 255, 255, 0);"=
>Stopping passive attacks is the low hanging fruit. This should be taken fir=
st.</span></div><div><span style=3D"background-color: rgba(255, 255, 255, 0)=
;"><br></span></div><div><span style=3D"background-color: rgba(255, 255, 255=
, 0);">Automated and secure peer authentication in a mesh network is a huge t=
opic. One of the unsolved problems in computer science.</span></div><div><sp=
an style=3D"background-color: rgba(255, 255, 255, 0);"><br></span><div><div>=
<span style=3D"background-color: rgba(255, 255, 255, 0);">A simple 'who is t=
hat' by&nbsp;asking for the fingerprint of your peers from your other peers i=
s a very simple way to get 'some' authentication. &nbsp;Semi-trusted index n=
odes also is a low hanging fruit for authentication.</span></div></div></div=
></div></div></blockquote><div><br></div><div>It is the implication of wides=
pread authentication that is at issue. Clearly there are ways to implement i=
t using a secure side channels.</div><br><blockquote type=3D"cite"><div><div=
><div><div><span style=3D"background-color: rgba(255, 255, 255, 0);">However=
, let's first get u<font>nauthenticated encryption. Force the attackers to u=
se active attacks. (That are thousands times more costly to couduct).</font>=
</span></div></div><br>Sent from my iPhone</div><div><br>On 29 Jun 2016, at 0=
0:36, Gregory Maxwell via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br><br></div><blockquote type=3D"cite"><div><span>On Tue, Jun 28, 2016 at 9:=
22 PM, Eric Voskuil via bitcoin-dev</span><br><span>&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:</span><br><blockquote type=3D"cite"><span>An "out of band key c=
heck" is not part of BIP151.</span><br></blockquote><span></span><br><span>I=
t has a session ID for this purpose.</span><br><span></span><br><blockquote t=
ype=3D"cite"><span>It requires a secure channel and is authentication. So BI=
P151 doesn't provide the tools to detect an attack, that requires authentica=
tion. A general requirement for authentication is the issue I have raised.</=
span><br></blockquote><span></span><br><span>One might wonder how you ever u=
se a Bitcoin address, or even why we</span><br><span>might guess these email=
s from "you" aren't actually coming from the</span><br><span>NSA.</span><br>=
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a=
 href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></=
div></blockquote></div></blockquote></div></div></blockquote></div></blockqu=
ote></body></html>=

--Apple-Mail-18BE1868-157C-4975-AEC1-642652226EEC--