Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F340AA1E for ; Tue, 28 Jun 2016 22:33:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C5AD5168 for ; Tue, 28 Jun 2016 22:33:39 +0000 (UTC) Received: by mail-lf0-f49.google.com with SMTP id q132so21164889lfe.3 for ; Tue, 28 Jun 2016 15:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k8hocvBlT15dqJj5tUaDAXVyaqvckfp9HzhcOM6R1LM=; b=hWFxcKnAyRO/IlIg8gpL5fRN2abyn7vaIxypU4A6hj8skBJp+ZEqzpJKgRlQcuNd9l Z1ThRuoqCt1GVGE5ZAOWZp+3U1my2ZKUfmTyo7scsrgJwcP4rPyNFNIpFszphRlnFqld cznuU1UEqLkMOwIrMAfQedNbGe+TNWDS6tst7qG25FYblNN/W4XB6EH8uZwBGOn4xnW0 oemmGiWht3tZuq9yxVPITygC/oP/UQuEmrdajnM9Kh5kxrcksR2iyNHi8Epavxle/9P7 XctRMt9+xoVGAUhA4fT6gk4Bto2EtwvwtDRlUyPjMUZ+D7SLcDrcGYMM7g1EDG+xOJAD bgGw== 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=k8hocvBlT15dqJj5tUaDAXVyaqvckfp9HzhcOM6R1LM=; b=M33KYnwGS1yzyqzREQM3EeK+tD7qA1rXtGbunAlmMjimLpiw0Wl2mOzURneli+/jhJ w5FBCzelLjDvQ8xrO/05GtROPog/PHnO0Y76OODiSMwtoaW+iMFS9US0uDrs+pm+nN2Z xIg0cOqJhox0NxHEdDFlIH3GQroaQ8gAkmM+/nRFKE8kJg4IQ/yfhVq2LyXZGyMPgnpT 2jZJIeYTZazIv6vkPMGbAoo5NrKlczhZwSEWMl7teK5zIp9MXwueZJhWjzmlKfCChwKj zUYUAcHCx8lTZLRHnRvKey93GTw+vpMom3iCLPZbTDsdDHMoTFziftkXYorGZSkCJ6nl LtDA== X-Gm-Message-State: ALyK8tJJh2q5Ew00m+w6unhgzif7Ny82/5LBm/bA0lzm8xkB8Giix9wSJctsNKuhzxtxhg== X-Received: by 10.25.38.206 with SMTP id m197mr2139325lfm.201.1467153217870; Tue, 28 Jun 2016 15:33:37 -0700 (PDT) Received: from [192.168.0.103] (188-115-185-127.broadband.tenet.odessa.ua. [188.115.185.127]) by smtp.gmail.com with ESMTPSA id 134sm82617ljj.48.2016.06.28.15.33.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 15:33:36 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE Mime-Version: 1.0 (1.0) From: Cameron Garnham X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 29 Jun 2016 01:33:35 +0300 Content-Transfer-Encoding: 7bit Message-Id: 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> <20160628201447.GA1148@fedora-21-dvm> <4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org> <20160628203605.GA1328@fedora-21-dvm> To: Eric Voskuil X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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 X-Mailman-Approved-At: Tue, 28 Jun 2016 22:34:27 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 22:33:41 -0000 --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 wrote: >=20 > Hi Cameron, good to hear from you! >=20 >> On Jun 28, 2016, at 11:40 PM, Cameron Garnham 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 wrote: >>>=20 >>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev >>> 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

There are two different topics mixed up here.

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

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

The fist requires link-level enc= ryption and authentication.

The second requires identity authentication.

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.

It is important not to mixup link-level authentication and no= de-level authentication.

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>
If you manually add a friends node; at t= his point you wish to have node-level authentication.  However, this ma= y (and probably should) happen out-of-band.


Sent from my iPhone

On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:

Hi Cameron, good to hear from you!

On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> wrote:

Unauthenticated link level encryption is wonderful! MITM attacks are ove= rrated; as they require an active attacker.
<= 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.

Stopping passive attacks is the l= ow hanging fruit. This should be taken first.

Automated and secure peer au= thentication in a mesh network is a huge topic. One of the unsolved problems= in computer science.

A simple 'who is that' by asking for the finger= print of your peers from your other peers is a very simple way to get 'some'= authentication.  Semi-trusted index nodes also is a low hanging fruit f= or authentication.
It is the implication of widespread authentication that is at is= sue. Clearly there are ways to implement it using a secure side channels.
However, let's first get unauthenti= cated encryption. Force the attackers to use active attacks. (That are thous= ands times more costly to couduct).

Sent from m= y iPhone

On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin= -dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:

On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-d= ev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
An "out of band key check" is not part of BIP151.

It has a session ID for this purp= ose.

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.

One might wonder how you ever use a Bitcoin address, or even why= we
might guess these emails from "you" aren't actually comi= ng from the
NSA.
___________________________= ____________________
bitcoin-dev mailing list
bitcoin-dev@lists= .linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/bitcoin-dev
= --Apple-Mail-E037BA1B-9F8E-4326-9965-2F50C66AF6CE--