Content-Type: multipart/alternative;
	boundary=Apple-Mail-18BE1868-157C-4975-AEC1-642652226EEC
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
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>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list


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