Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4896625A for ; 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 ; Tue, 28 Jun 2016 23:29:14 +0000 (UTC) Received: by mail-wm0-f42.google.com with SMTP id r201so48790406wme.1 for ; 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 X-Mailer: iPhone Mail (13F69) In-Reply-To: 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> <20160628201447.GA1148@fedora-21-dvm> <4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org> <20160628203605.GA1328@fedora-21-dvm> To: Cameron Garnham 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 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 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 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 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 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 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-18BE1868-157C-4975-AEC1-642652226EEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
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.

e

On Jun 29, 2016, a= t 12:33 AM, Cameron Garnham <da2ce7@g= mail.com> wrote:


There are two different topics mixed up h= ere.

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

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

= The fist requires link-level encryption and authentication.

The second requ= ires identity authentication.

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

It is important not to mixup l= ink-level authentication and node-level authentication.

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

If you= manually add a friends node; at this point you wish to have node-level auth= entication.  However, this may (and probably should) happen out-of-band= .


Sent from my iPhone

On 29 Jun 2016, at 01:07, Eric Vosk= uil <eric@voskuil.org> wrote:<= br>
Hi Cameron, g= ood to hear from you!

On Jun 28, 2016, at 11:40 PM, Cam= eron Garnham <da2ce7@gmail.com>= ; wrote:

Unauthenticated link level encryption i= s wonderful! MITM attacks are overrated; as they require an active attacker.=

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.

Stopping passive attacks is the low hanging fruit. This should be taken fir= st.

Automated and secure peer authentication in a mesh network is a huge t= opic. One of the unsolved problems in computer science.

= A simple 'who is t= hat' by asking for the fingerprint of your peers from your other peers i= s a very simple way to get 'some' authentication.  Semi-trusted index n= odes also is a low hanging fruit for authentication.

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.

However= , let's first get unauthenticated encryption. Force the attackers to u= se active attacks. (That are thousands times more costly to couduct).=

Sent from my iPhone

On 29 Jun 2016, at 0= 0:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<= br>
= --Apple-Mail-18BE1868-157C-4975-AEC1-642652226EEC--