diff options
author | Nick ODell <nickodell@gmail.com> | 2016-06-28 18:06:41 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-06-29 00:06:43 +0000 |
commit | 5fb93b2f653b9fb31075d839949739738231408c (patch) | |
tree | eb2811c925eeab87dbaee611f9fc39be4b9749eb /16 | |
parent | 98fb54c6bbba35177c32cd95f3666e41b81f4d47 (diff) | |
download | pi-bitcoindev-5fb93b2f653b9fb31075d839949739738231408c.tar.gz pi-bitcoindev-5fb93b2f653b9fb31075d839949739738231408c.zip |
Re: [bitcoin-dev] BIP 151
Diffstat (limited to '16')
-rw-r--r-- | 16/3f375f64b417c0bb94166ac983f2cc0cfeb250 | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/16/3f375f64b417c0bb94166ac983f2cc0cfeb250 b/16/3f375f64b417c0bb94166ac983f2cc0cfeb250 new file mode 100644 index 000000000..c38b646a7 --- /dev/null +++ b/16/3f375f64b417c0bb94166ac983f2cc0cfeb250 @@ -0,0 +1,204 @@ +Return-Path: <nickodell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 39ADDA55 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Jun 2016 00:06:43 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com + [209.85.214.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9119319B + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Jun 2016 00:06:42 +0000 (UTC) +Received: by mail-ob0-f177.google.com with SMTP id xn17so3474945obc.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 28 Jun 2016 17:06:42 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=2VFw/RsuoZpzBdOaOuI6B4TJTnfWyju9pz4L8cnk3wI=; + b=hZvs430K30QdE7X55udG4AaVimNQZf/B8B4slbd7dwoKZlWHAstDcC8MVLSCotLvw9 + EnF92TSaE+jQn1uci18SDaA2cS+h4sz2AX3MBYcz2Oxgg4iUupkHuAxlGzSjwvBTLI/h + JCqfSvRq1vjQIF96GRa9FUfI7d0nn+bfje/f4JXRc3wyaYFaaS8ZgfyZYvwv8m6SqtiK + eEWNYnTz+LMZZeqxDrWUyPOYqh0afXSfs9AoF3G6FybAhzrAxhvM7J9ZTye52Mqch7E4 + T66thexDQjAABp1csvFT25nhlpcvDa5QjhAnpGqN0MwFj23CRxHgbHKyDnsSDYzk2SKB + 6BQQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to; + bh=2VFw/RsuoZpzBdOaOuI6B4TJTnfWyju9pz4L8cnk3wI=; + b=YLfWIfMU9drTufAvyNw+hXjhfQE6RUs+J5SBr5lHhU+YGdIAYDMfHdwGTtQc60z41L + eu9jlTs2vRSGZNhWaWPODPTx3eZQ0DsgeKXnDPI2mo5+j3oWJP5KYSKLBeUnRCJk0Mh9 + PnKhZrRS/Z85Gr5L9MrQn3LwrMhWeyz/BMIoqo4vv2PG78YAB20+M63/31eYAfT4vFSv + tlNqe9NBmsD0PwsqBZE8LJ550woaNjP3JeaYKP7jT6qfN1HV+DiIt9rVVVUvNgHuFQMK + p9rDpg9uETRXUDGjKP1HZ3cGjY4DbO3zDwNNgCRKErF7+UxpmkIM+suSSTGMa9h+D8EE + z8ig== +X-Gm-Message-State: ALyK8tJeq6vRQTYhSx1EIGMFJRU0KUhHgQXdOjopVgBQVa78Ab3Q7zlxfiLNUjXqFAFSKCk40V77ncaH+4T6kg== +X-Received: by 10.157.1.107 with SMTP id 98mr3851170otu.17.1467158801795; Tue, + 28 Jun 2016 17:06:41 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.182.217.106 with HTTP; Tue, 28 Jun 2016 17:06:41 -0700 (PDT) +In-Reply-To: <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> + <2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@voskuil.org> +From: Nick ODell <nickodell@gmail.com> +Date: Tue, 28 Jun 2016 18:06:41 -0600 +Message-ID: <CANN4kmfqbWwPhD1kyWMsrRhDJaniu3f3Ca_-LSuNawDwY1_uvw@mail.gmail.com> +To: Eric Voskuil <eric@voskuil.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + 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 +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: Wed, 29 Jun 2016 00:06:43 -0000 + +>They both require authentication, + +Yeah, but not the same *sort* of authentication. As a trivial example, +you could have ten servers that sign long-term keys for nodes. All +that they need to check is that the node requesting a signature owns +the corresponding IP address. On the other hand, 'evil nodes' is a +subjective quality that is hard to assess automatically. + +>and if you intend to connect to potentially evil nodes you aren't securing anything + +Bitcoin is designed with the assumption that some of the nodes you +connect to might be evil. Sure, if 100% of the nodes you're connected +to are evil, you're screwed. However, we shouldn't avoid protecting +people from someone on the same coffee-shop network, just because the +same mitigation won't work against a nation-state. + +On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> Your description of the two scenarios reduces to one. They both require +> authentication, and if you intend to connect to potentially evil nodes you +> aren't securing anything with link level security except the knowledge that +> your potentially evil node connection remains so. +> +> e +> +> On Jun 29, 2016, at 12:33 AM, Cameron Garnham <da2ce7@gmail.com> wrote: +> +> +> 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 +> to stop. However BIP151 doesn't intend to protect against connecting to evil +> Bitcoin Nodes. +> +> It is important not to mixup link-level authentication and node-level +> authentication. +> +> When your client picks random nodes to connect to, you are not considered +> whom in particular runs 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 authentication. However, this may (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 +> overrated; as they require an active attacker. +> +> +> This is not really the case with Bitcoin. A MITM attack does not require +> that the attacker find a way to inject traffic into the communication +> between nodes. Peers will connect to the attacker directly, or accept +> connections directly from it. Such attacks can be easier than even passive +> attacks. +> +> Stopping passive attacks is the low hanging fruit. This should be taken +> first. +> +> Automated and secure peer authentication 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 fingerprint 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 for authentication. +> +> +> It is the implication of widespread authentication that is at issue. Clearly +> there are ways to implement it using a secure side channels. +> +> However, let's first get unauthenticated encryption. Force the attackers to +> use active attacks. (That are thousands times more costly to couduct). +> +> Sent from my iPhone +> +> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> 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. +> +> +> It has a session ID for this purpose. +> +> It requires a secure channel and is authentication. So BIP151 doesn't +> provide the tools to detect an attack, that requires authentication. A +> general requirement for authentication 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 coming from the +> NSA. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + |