Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote: > Proposal: > > > BIP: ??? > Layer: Peer Services > Title: Version 2 Peer-to-Peer Message Transport Protocol > Author: Jonas Schnelli > Status: Draft > Type: Standards Track > Created: 2019-03-08 > License: PD > > > == Abstract == > > This BIP describes a new Bitcoin peer to peer transport protocol with > opportunistic encryption. > > == Motivation == > > The current peer-to-peer protocol is partially inefficient and in plaintext. > > With the current unencrypted message transport, BGP hijack, > block delay attacks > and message tempering are inexpensive and can be executed in a covert way > (undetectable MITM)[https://btc-hijack.ethz.ch/files/btc_hijack.pdf > Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A. > Zohar, L.Vanbever]. This proposal does not provide mitigation for BGP hijacking, message tampering or delaying, between anonymous peers. > Adding opportunistic encryption introduces a high risk for attackers of > being detected. Peer operators can compare encryption session IDs This is only possible if the peers have access to a secure/trusted side channel between them. In other words, this does not benefit anonymous peers. It also seems like quite a stretch to consider it creating "high risk" for the attacker, since the chances of any given pair of peers actually comparing session IDs over a secure channel seems extremely remote. > or use other form of authentication schemes name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki > BIP150] to identify an attack. Authentication helps mitigate attacks by requiring the identity of the peer (based only on the presumption that a trusted peer wouldn't attack). This provides no benefit to anonymous peers. Data communicated between peers is entirely public. Unlike other systems that maintain data integrity through encryption, Bitcoin relies on validation. Encrypting public data between anonymous peers is pointless, and thus counterproductive from an engineering and software security standpoint. More importantly Bitcoin system security *requires* widespread anonymous participation. It's generally not a good idea to implement features that backfire if they actually get widespread use. While we cannot prevent people from using VPNs, incorporating them into the protocol is counterproductive from a system security standpoint. > Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256 > checksum truncated to 4 bytes. Roughly the same amount of computation power > would be required for encrypting and authenticating a peer-to-peer > message with ChaCha20 & Poly1305. The proposal overlooks the simple alternatives of (1) not validating the checksum, which is never necessary, and (2) proposing a protocol change to drop the checksum altogether. The former requires no protocol change and the latter can allow the checksum to be dropped in all messages except "version" given a simple protocol version number increment (i.e. no need to consume a service bit), saving not only the CPU resource but also network bandwidth. > Additionally, this BIP describes a way how data manipulation (blocking or > tempering commands by an intercepting TCP/IP node) would be identifiable > by the communicating peers. The only such method described is manual comparison of session ID's between trusted parties over a secure side channel. > Encrypting traffic between peers is already possible with VPN, tor, > stunnel, > curveCP or any other encryption mechanism on a deeper OSI level, > however, most > of those solutions require significant knowhow in how to setup such a > secure > channel and are therefore not widely deployed. Yet this is exactly what a secure side channel is. Furthermore, being manual, not only would it also suffer from not being widely deployed, but also widely ignored. > == Specification == > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are > to be > interpreted as described in RFC > 2119[https://tools.ietf.org/html/rfc2119 > RFC 2119]. > > > A peer that supports the message transport protocol as defined in this > proposal > MUST accept encryption requests from all peers. > > Both communication direction share the same shared-secret but have > different > symmetric cipher keys. > > The encryption handshake MUST happen before sending any other messages > to the > responding peer. > > If the responding peer closes the connection after sending the handshake > request, the initiating peer MAY try to connect again with the v1 > peer-to-peer > transport protocol. Such reconnects allow an attacker to "downgrade" the > encryption to plaintext communication and thus, accepting v1 connections > MUST > not be done when the Bitcoin peer-to-peer network uses almost only v2 >
Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
Hi Dave Thanks for the review... >> Short Command ID >> >> To save valuable bandwidth, the v2 message format supports message command >> short IDs for message types with high frequency. The ID/string mapping is a >> peer to peer arrangement and MAY be negotiated between the initiating and >> responding peer. > > Why is this optional and only specified here for some message types > rather than being required by v2 and specified for all message types? > There's only 26 different types at present[1], so it seems better to > simply make this a one-byte fixed-length field than it is to deal with > variable size, mapping negotiation, per-peer mapping in general, and > (once the network is fully v2) the dual-logic of being able to process > messages either from a short ID or a full command name. One thing I was trying to avoid is some sort of central planing. Strings as message command identifier do usually bring some sort of collision resistance when competitive implementations work on different features. An example are the service bits where we AFAIK had an (almost) collision. This is the main reason why I think we should avoid setting the short IDs mandatory (naturally by not giving all commands a short ID). Short IDs do probably make most sense for messages with high frequency. By only giving frequent messages a short ID, we may avoid ID collisions in future. Short IDs can be altered with the message protocol version (not the transport protocol, the message protocol like 70015, etc.) and new/different negation should be straight forward. I just ran some random stats (non representative) and inv makes about 66% of all messages (pruned peer, not helping IBDing others) followed by tx and getdata. Those three probably deserve a short ID. I have no big objection against adding short IDs for other commands as long as we don’t make short IDs mandatory. Though, there are little benefits for commands like VERSION, FILTERxx, SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs. /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
On Sun, Mar 24, 2019 at 09:29:10AM -0400, David A. Harding via bitcoin-dev wrote: > Why is this optional and only specified here for some message types > rather than being required by v2 and specified for all message types? Gregory Maxwell discussed this with me on IRC[1]. My summary of our conversation: Although the BIP can easily allocate short-ids to all existing messages, anyone who wants to add an additional protocol message later will need to coordinate their number allocation with all other developers working on protocol extensions. This includes experimental and private extensions. At best this would be annoying, and at worst it'd be another set of bikeshed problems we'd waste time arguing about. Allowing nodes to continue using arbitrary command names eliminates this coordination problem. Yet we can also gain the advantage of saving bandwidth by allowing mapping (with optional negotiation) of short-ids. Now that I understand the motivation, this part of the proposal makes sense to me. -Dave [1] http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-24.html#l-159 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wrote:
> === v2 Messages Structure ===
>
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte short
> command ID)
> [...]
> The command field MUST start with a byte that defines the length of the ASCII
> command string up to 12 chars (1 to 12) or a short command ID (see below).
> [...]
> Short Command ID
>
> To save valuable bandwidth, the v2 message format supports message command
> short IDs for message types with high frequency. The ID/string mapping is a
> peer to peer arrangement and MAY be negotiated between the initiating and
> responding peer.
Why is this optional and only specified here for some message types
rather than being required by v2 and specified for all message types?
There's only 26 different types at present[1], so it seems better to
simply make this a one-byte fixed-length field than it is to deal with
variable size, mapping negotiation, per-peer mapping in general, and
(once the network is fully v2) the dual-logic of being able to process
messages either from a short ID or a full command name.
Thanks,
-Dave
[1] src/protocol.cpp:
const static std::string allNetMessageTypes[] = {
NetMsgType::VERSION,
NetMsgType::VERACK,
NetMsgType::ADDR,
NetMsgType::INV,
NetMsgType::GETDATA,
NetMsgType::MERKLEBLOCK,
NetMsgType::GETBLOCKS,
NetMsgType::GETHEADERS,
NetMsgType::TX,
NetMsgType::HEADERS,
NetMsgType::BLOCK,
NetMsgType::GETADDR,
NetMsgType::MEMPOOL,
NetMsgType::PING,
NetMsgType::PONG,
NetMsgType::NOTFOUND,
NetMsgType::FILTERLOAD,
NetMsgType::FILTERADD,
NetMsgType::FILTERCLEAR,
NetMsgType::REJECT,
NetMsgType::SENDHEADERS,
NetMsgType::FEEFILTER,
NetMsgType::SENDCMPCT,
NetMsgType::CMPCTBLOCK,
NetMsgType::GETBLOCKTXN,
NetMsgType::BLOCKTXN,
};
signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
