From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CF26C3E for ; Mon, 25 Mar 2019 06:33:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5679C2D5 for ; Mon, 25 Mar 2019 06:33:01 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id v12so5797417pgq.1 for ; Sun, 24 Mar 2019 23:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to; bh=Up+77gtUlOVApNMQEGsaO3IxXXbt/MffONBAlUlTTiQ=; b=zb6WijNhEm93+BET6f7XKapROljrZBEK144N2ktf9QGEPABoI9hChmvkExUWWQf5VW e3elXx5al3w/FTwSG6JqKLgRQRV7zipoplNWdYOJZaKDSzMP21XJXPBJdWLE2QYrvgs2 +t670zn9G14zSsGDz1WqlJFyqOrOY/yJmHPtMKo4jYntFNm9iay2InbjOTNKajmLyJzY sAHjpIZ0fFN1cCRFF34lVxVTxOYYRzYljp7YA9V67Q7oWnYBHvuP8I2yLVV+MFeJut9g EUGgIcCaiHXwpFwp//Dt6HgiemzYZ5qbpAtsiA8AlGkZhsVbYlNtvuUepVpwRybu+Sm4 vp+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to; bh=Up+77gtUlOVApNMQEGsaO3IxXXbt/MffONBAlUlTTiQ=; b=nzUmJMq+k/DQmeBs7kLOnz3Krs3uPdlqWrE1T4gPV2/WnNbxWN+wRMViiIBzWihjds Q+XuYMyAeGvxI7SreyiAIlcbXXFbVdRtYcjCgV3PVKbb0AUQ5ne3D5yla8hLiUhVoFtk SqZ6bmuPuWIu5c9cWG+XnwzsmNEiXExjbeyi9MllBxIKa1xv94BM8YR20wtJCOLzOQZd rLWVBhaZ3lDeexBBrVVxhZpOtnADmyFcfDHMwJ0Iq9CT857pN9Vi3wfck+ltvouKmWzn e4buZKiooEcoNk8AZ4YKxEKtdjcLhPmHq0cjJy9FGxBGZHOGhHDlGzGzbRVGUWrdEr5L kWNA== X-Gm-Message-State: APjAAAX81PDPl22hCb977TuufBl5/0p44vOTC5wxJzLe5x9rjUmPs+uZ Awlzo1IGxzSCEAnShw+o0pzEf8dZTPs= X-Google-Smtp-Source: APXvYqyUxLDuYBWSMLhVKBGBWV9gpTe54NuzbHGtRb5MvHOhQ+VS42o9rRgFIthWmFhiNqzGa2OkKg== X-Received: by 2002:a63:78ce:: with SMTP id t197mr8611905pgc.314.1553495580521; Sun, 24 Mar 2019 23:33:00 -0700 (PDT) Received: from ?IPv6:2601:600:a080:16bb:200a:1d47:7ff8:ea41? ([2601:600:a080:16bb:200a:1d47:7ff8:ea41]) by smtp.gmail.com with ESMTPSA id l19sm18310762pff.185.2019.03.24.23.32.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 23:32:59 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch> From: Eric Voskuil Openpgp: preference=signencrypt Message-ID: Date: Sun, 24 Mar 2019 23:32:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dmvy1y83MVUqjyh25KUzKKLwB4E6FIVoy" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE 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: Mon, 25 Mar 2019 06:42:35 +0000 Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) 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: Mon, 25 Mar 2019 06:33:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dmvy1y83MVUqjyh25KUzKKLwB4E6FIVoy Content-Type: multipart/mixed; boundary="lA2jSGqdflK1bJxe50FzOjv2n3hqmfx8Q"; protected-headers="v1" From: Eric Voskuil To: bitcoin-dev@lists.linuxfoundation.org Message-ID: Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) References: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch> In-Reply-To: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch> --lA2jSGqdflK1bJxe50FzOjv2n3hqmfx8Q Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote: > Proposal: >=20 > 
> =C2=A0 BIP: ???
> =C2=A0 Layer: Peer Services
> =C2=A0 Title: Version 2 Peer-to-Peer Message Transport Protocol
> =C2=A0 Author: Jonas Schnelli 
> =C2=A0 Status: Draft
> =C2=A0 Type: Standards Track
> =C2=A0 Created: 2019-03-08
> =C2=A0 License: PD
>
>=20 > =3D=3D Abstract =3D=3D >=20 > This BIP describes a new Bitcoin peer to peer transport protocol with=C2= =A0 > opportunistic encryption. >=20 > =3D=3D Motivation =3D=3D >=20 > The current peer-to-peer protocol is partially inefficient and in plain= text. >=20 > With the current unencrypted message transport, BGP hijack, > block delay attacks=C2=A0 > and message tempering are inexpensive and can be executed in a covert w= ay=C2=A0 > (undetectable MITM)[https://btc-hijack.ethz.ch/files/btc_hijack.pd= f=C2=A0 > Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki,= A.=C2=A0 > 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 remo= te. > or use other form of authentication schemes name=3D"bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.m= ediawiki=C2=A0 > 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-SHA25= 6=C2=A0 > checksum truncated to 4 bytes. Roughly the same amount of computation p= ower=C2=A0 > 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=C2=A0 > tempering commands by an intercepting TCP/IP node) would be identifiabl= e > 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,=C2=A0 > curveCP or any other encryption mechanism on a deeper OSI level, > however, most=C2=A0 > of those solutions require significant knowhow in how to setup such a > secure=C2=A0 > 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. > =3D=3D Specification =3D=3D >=20 >
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", > "SHOULD NOT", "RECOMMENDED", =C2=A0"MAY", and "OPTIONAL" in this docume= nt are > to be > interpreted as described in RFC > 2119[https://tools.ietf.org/html/rfc2119=C2=A0 > RFC 2119]. >
>=20 > A peer that supports the message transport protocol as defined in this > proposal=C2=A0 > MUST accept encryption requests from all peers. >=20 > Both communication direction share the same shared-secret but have > different=C2=A0 > symmetric cipher keys. >=20 > The encryption handshake MUST happen before sending any other messages > to the=C2=A0 > responding peer. >=20 > If the responding peer closes the connection after sending the handshak= e=C2=A0 > request, the initiating peer MAY try to connect again with the v1 > peer-to-peer=C2=A0 > transport protocol. Such reconnects allow an attacker to "downgrade" th= e=C2=A0 > encryption to plaintext communication and thus, accepting v1 connection= s > MUST=C2=A0 > not be done when the Bitcoin peer-to-peer network uses almost only v2=C2= =A0 > communication. >=20 >=20 > =3D=3D=3D NODE_P2P_V2 =3D=3D=3D >=20 > Peers supporting the transport protocol after this proposal MUST signal= =C2=A0 > NODE_P2P_V2 > 
> NODE_P2P_V2 =3D (1 << 11)
>
>=20 > A peer usually learns an address along with the expected service flags > which=C2=A0 > MAY be used to filter possible outbound peers. >=20 > A peer signaling NODE_P2P_V2 MUST accept encrypted > communication=C2=A0 > specified in this proposal. >=20 > Peers MAY only make outbound connections to peers supporting=C2=A0 > NODE_P2P_V2. >=20 > =3D=3D=3D Handshake =3D=3D=3D =2E.. > =3D=3D=3D=3D Short Command ID =3D=3D=3D=3D The shortening of message identifiers hardly seems worth the effort. Dropping the checksum seems a much easier way to save more on the wire (and in the CPU). > =3D=3D=3D Risks =3D=3D=3D >=20 > The encryption does not include an authentication scheme. > This BIP does not=20 > cover a proposal to avoid MITM attacks during the encryption > initialization. Then to be clear it cannot prevent MITM attacks. The only actual mitigation requires manual comparison of session IDs after each connection (and reconnection). > However, peers MUST show the session-id to the user on request which > allows to identify a MITM by a manual verification on a secure channel.= This scenario presumes that the two peers are operated by individuals who know and trust each other and have the ability to communicate over a secure side channel, and will each extract the session ID from their respective peers and use the side channel to compare them. Not only does this not support anonymous peering, it's not clear what process would exist to make this actually useful in practice. > Optional authentication schemes may be covered by other proposals name=3D"bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.m= ediawiki=C2=A0 > BIP150]. >=20 > An attacker could delay or halt v2 protocol enforcement by providing a=C2= =A0 > reasonable amount of peers not supporting the v2 protocol. >=20 > =3D=3D Compatibility =3D=3D >=20 > This proposal is backward compatible (as long as not enforced). Kudos for making this second attempt backward compatible. > Non-supporting=C2=A0 > peers can still use unencrypted communications. >=20 > =3D=3D Reference implementation =3D=3D > * Complete Bitcoin Core implementation: > https://github.com/bitcoin/bitcoin/pull/14032 > * Reference implementation of the AEAD in C: > https://github.com/jonasschnelli/chacha20poly1305 --lA2jSGqdflK1bJxe50FzOjv2n3hqmfx8Q-- --dmvy1y83MVUqjyh25KUzKKLwB4E6FIVoy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJcmHYaAAoJEDzYwH8LXOFOSj8H/RieGp8PxhjMGQ3mfgEE9Drz urRGkBU4DCoyQHrE/291aE8/QWdkXMkOYdNDv4/je4ceddiM95kk7fBd6m/yiRGJ /D/FIedJV6fi21pmoFlUlYhZjXG8NRcldgPd0iwIDnjzkzNnyZB4e5MuPafHaT9h rZEbdvl8RX4p4vRlZC3DhEyu5sTaw+/J49LweneSf6IZNhp+jRdNKLHMberNun5I /k+6rIHJlirJDEhFYjWIkrKAnhTbz6p4vTMAU2ihruyhvzoTrxBYui5VRi5gybFP DCBBgxgGD2GGfCHBiT77bIR00W8rnVUWuEi3ID/yslD87lxoeqj5jlHsI+TmdCs= =PaJP -----END PGP SIGNATURE----- --dmvy1y83MVUqjyh25KUzKKLwB4E6FIVoy--