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 <e...@voskuil.org> wrote: > > Hi Cameron, good to hear from you! > >> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2...@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
