Content-Type: multipart/alternative;
	boundary=Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE
Mime-Version: 1.0 (1.0)
From: Cameron Garnham <da2ce7@gmail.com>
In-Reply-To: <A74C9C1E-07CE-4769-85BA-AA97F55167EC@voskuil.org>
Date: Wed, 29 Jun 2016 01:33:35 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>
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>
To: Eric Voskuil <eric@voskuil.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Precedence: list


--Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


There are two different topics mixed up here.

1. Link-level security (secure connection to the node we intended to connect=
 to).

2. Node-level security (aka; don't connect to a 'evil node').

The fist requires link-level encryption and authentication.

The second requires identity authentication.

You described the 'evil node' attack; that indeed needs an identity system t=
o stop. However BIP151 doesn't intend to protect against connecting to evil B=
itcoin Nodes.

It is important not to mixup link-level authentication and node-level authen=
tication.

When your client picks random nodes to connect to, you are not considered wh=
om in particular runs them. (Rather that you have a good random sample of th=
e network).

If you manually add a friends node; at this point you wish to have node-leve=
l authentication.  However, this may (and probably should) happen out-of-ban=
d.


Sent from my iPhone

> 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 over=
rated; 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 topi=
c. 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. Clear=
ly there are ways to implement it using a secure side channels.
>=20
>> However, let's first get unauthenticated encryption. Force the attackers t=
o 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@l=
ists.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-E037BA1B-9F8E-4326-9965-2F50C66AF6CE
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><br></div><div id=3D"AppleMailSignatur=
e">There are two different topics mixed up here.</div><div id=3D"AppleMailSi=
gnature"><br></div><div id=3D"AppleMailSignature">1. Link-level security (se=
cure connection to the node we intended to connect to).</div><div id=3D"Appl=
eMailSignature"><br></div><div id=3D"AppleMailSignature">2. Node-level secur=
ity (aka; don't connect to a 'evil node').</div><div id=3D"AppleMailSignatur=
e"><br></div><div id=3D"AppleMailSignature">The fist requires link-level enc=
ryption and authentication.</div><div id=3D"AppleMailSignature"><br></div><d=
iv id=3D"AppleMailSignature">The second requires identity authentication.</d=
iv><div id=3D"AppleMailSignature"><br></div><div id=3D"AppleMailSignature">Y=
ou described the 'evil node' attack; that indeed needs an identity system to=
 stop. However BIP151 doesn't intend to protect against connecting to evil B=
itcoin Nodes.</div><div id=3D"AppleMailSignature"><br></div><div id=3D"Apple=
MailSignature">It is important not to mixup link-level authentication and no=
de-level authentication.</div><div id=3D"AppleMailSignature"><br></div><div i=
d=3D"AppleMailSignature">When your client picks random nodes to connect to, y=
ou are not considered whom in particular runs them. (Rather that you have a g=
ood random sample of the network).</div><div id=3D"AppleMailSignature"><br><=
/div><div id=3D"AppleMailSignature">If you manually add a friends node; at t=
his point you wish to have node-level authentication. &nbsp;However, this ma=
y (and probably should) happen out-of-band.</div><div id=3D"AppleMailSignatu=
re"><br></div><div id=3D"AppleMailSignature"><br>Sent from my iPhone</div><d=
iv><br>On 29 Jun 2016, at 01:07, Eric Voskuil &lt;<a href=3D"mailto:eric@vos=
kuil.org">eric@voskuil.org</a>&gt; wrote:<br><br></div><blockquote type=3D"c=
ite"><div><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"><div><span></span></div><div><meta http-equiv=3D"content-type" conten=
t=3D"text/html; charset=3Dutf-8"><div></div><div><span style=3D"background-c=
olor: rgba(255, 255, 255, 0);">Hi Cameron, good to hear from you!</span></di=
v><div><br>On Jun 28, 2016, at 11:40 PM, Cameron Garnham &lt;<a href=3D"mail=
to:da2ce7@gmail.com">da2ce7@gmail.com</a>&gt; wrote:<br><br></div><blockquot=
e type=3D"cite"><div><meta http-equiv=3D"content-type" content=3D"text/html;=
 charset=3Dutf-8"><div><span style=3D"background-color: rgba(255, 255, 255, 0=
);">Unauthenticated link level encryption is wonderful! MITM attacks are ove=
rrated; as they require an active attacker.</span></div></div></blockquote><=
div><br></div><div>This is not really the case with Bitcoin. A MITM attack d=
oes not require that the attacker find a way to inject traffic into the comm=
unication between nodes. Peers will connect to the attacker directly, or acc=
ept connections directly from it. Such attacks can be easier than even passi=
ve attacks.</div><br><blockquote type=3D"cite"><div><div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);">Stopping passive attacks is the l=
ow hanging fruit. This should be taken first.</span></div><div><span style=3D=
"background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span styl=
e=3D"background-color: rgba(255, 255, 255, 0);">Automated and secure peer au=
thentication in a mesh network is a huge topic. One of the unsolved problems=
 in computer science.</span></div><div><span style=3D"background-color: rgba=
(255, 255, 255, 0);"><br></span><div><div><span style=3D"background-color: r=
gba(255, 255, 255, 0);">A simple 'who is that' by&nbsp;asking for the finger=
print of your peers from your other peers is a very simple way to get 'some'=
 authentication. &nbsp;Semi-trusted index nodes also is a low hanging fruit f=
or authentication.</span></div></div></div></div></div></blockquote><div><br=
></div><div>It is the implication of widespread authentication that is at is=
sue. Clearly there are ways to implement it using a secure side channels.</d=
iv><br><blockquote type=3D"cite"><div><div><div><div><span style=3D"backgrou=
nd-color: rgba(255, 255, 255, 0);">However, let's first get u<font>nauthenti=
cated encryption. Force the attackers to use active attacks. (That are thous=
ands times more costly to couduct).</font></span></div></div><br>Sent from m=
y iPhone</div><div><br>On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin=
-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@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-d=
ev</span><br><span>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</span><br><blockquo=
te type=3D"cite"><span>An "out of band key check" is not part of BIP151.</sp=
an><br></blockquote><span></span><br><span>It has a session ID for this purp=
ose.</span><br><span></span><br><blockquote type=3D"cite"><span>It requires a=
 secure channel and is authentication. So BIP151 doesn't provide the tools t=
o detect an attack, that requires authentication. A general requirement for a=
uthentication is the issue I have raised.</span><br></blockquote><span></spa=
n><br><span>One might wonder how you ever use a Bitcoin address, or even why=
 we</span><br><span>might guess these emails from "you" aren't actually comi=
ng from the</span><br><span>NSA.</span><br><span>___________________________=
____________________</span><br><span>bitcoin-dev mailing list</span><br><spa=
n><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></blockquo=
te></div></div></blockquote></body></html>=

--Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE--