path: root/b9/66b21798c1e0ffbd2bbc0c9d3ad3bc61a628e2

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CF26C3E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Mar 2019 06:33:01 +0000 (UTC)
Received: by mail-pg1-f193.google.com with SMTP id v12so5797417pgq.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>
	(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 <eric@voskuil.org>
Openpgp: preference=signencrypt
Message-ID: <d643191d-50da-3fd2-2903-383fbc66e654@voskuil.org>
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 <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: 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 <eric@voskuil.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <d643191d-50da-3fd2-2903-383fbc66e654@voskuil.org>
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
> <pre>
> =C2=A0 BIP: ???
> =C2=A0 Layer: Peer Services
> =C2=A0 Title: Version 2 Peer-to-Peer Message Transport Protocol
> =C2=A0 Author: Jonas Schnelli <dev@jonasschnelli.ch>
> =C2=A0 Status: Draft
> =C2=A0 Type: Standards Track
> =C2=A0 Created: 2019-03-08
> =C2=A0 License: PD
> </pre>
>=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)<ref>[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]</ref>.

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 <ref=C2=A0
> name=3D"bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.m=
ediawiki=C2=A0
> BIP150]</ref> 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
> <blockquote>
> 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<ref>[https://tools.ietf.org/html/rfc2119=C2=A0
> RFC 2119]</ref>.
> </blockquote>
>=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
> <code>NODE_P2P_V2</code>
> <pre>
> NODE_P2P_V2 =3D (1 << 11)
> </pre>
>=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 <code>NODE_P2P_V2</code> MUST accept encrypted
> communication=C2=A0
> specified in this proposal.
>=20
> Peers MAY only make outbound connections to peers supporting=C2=A0
> <code>NODE_P2P_V2</code>.
>=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 <ref=C2=
=A0
> name=3D"bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.m=
ediawiki=C2=A0
> BIP150]</ref>.
>=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--