Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-25 📝 Original message:On 03/22/2019 02:04 PM, ...
📅 Original date posted:2019-03-25
📝 Original message:On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote:
> Proposal:
>
> <pre>
> BIP: ???
> Layer: Peer Services
> Title: Version 2 Peer-to-Peer Message Transport Protocol
> Author: Jonas Schnelli <dev at jonasschnelli.ch>
> Status: Draft
> Type: Standards Track
> Created: 2019-03-08
> License: PD
> </pre>
>
> == 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)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
> Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
> 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 remote.
> or use other form of authentication schemes <ref
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> 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-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 ==
>
> <blockquote>
> 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<ref>[https://tools.ietf.org/html/rfc2119
> RFC 2119]</ref>.
> </blockquote>
>
> 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
> communication.
>
>
> === NODE_P2P_V2 ===
>
> Peers supporting the transport protocol after this proposal MUST signal
> <code>NODE_P2P_V2</code>
> <pre>
> NODE_P2P_V2 = (1 << 11)
> </pre>
>
> A peer usually learns an address along with the expected service flags
> which
> MAY be used to filter possible outbound peers.
>
> A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted
> communication
> specified in this proposal.
>
> Peers MAY only make outbound connections to peers supporting
> <code>NODE_P2P_V2</code>.
>
> === Handshake ===
...
> ==== Short Command ID ====
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).
> === Risks ===
>
> The encryption does not include an authentication scheme.
> This BIP does not
> 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
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> BIP150]</ref>.
>
> An attacker could delay or halt v2 protocol enforcement by providing a
> reasonable amount of peers not supporting the v2 protocol.
>
> == Compatibility ==
>
> This proposal is backward compatible (as long as not enforced).
Kudos for making this second attempt backward compatible.
> Non-supporting
> peers can still use unencrypted communications.
>
> == Reference implementation ==
> * Complete Bitcoin Core implementation:
> https://github.com/bitcoin/bitcoin/pull/14032
> * Reference implementation of the AEAD in C:
> https://github.com/jonasschnelli/chacha20poly1305
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190324/87025ec1/attachment.sig>;
📝 Original message:On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote:
> Proposal:
>
> <pre>
> BIP: ???
> Layer: Peer Services
> Title: Version 2 Peer-to-Peer Message Transport Protocol
> Author: Jonas Schnelli <dev at jonasschnelli.ch>
> Status: Draft
> Type: Standards Track
> Created: 2019-03-08
> License: PD
> </pre>
>
> == 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)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
> Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
> 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 remote.
> or use other form of authentication schemes <ref
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> 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-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 ==
>
> <blockquote>
> 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<ref>[https://tools.ietf.org/html/rfc2119
> RFC 2119]</ref>.
> </blockquote>
>
> 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
> communication.
>
>
> === NODE_P2P_V2 ===
>
> Peers supporting the transport protocol after this proposal MUST signal
> <code>NODE_P2P_V2</code>
> <pre>
> NODE_P2P_V2 = (1 << 11)
> </pre>
>
> A peer usually learns an address along with the expected service flags
> which
> MAY be used to filter possible outbound peers.
>
> A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted
> communication
> specified in this proposal.
>
> Peers MAY only make outbound connections to peers supporting
> <code>NODE_P2P_V2</code>.
>
> === Handshake ===
...
> ==== Short Command ID ====
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).
> === Risks ===
>
> The encryption does not include an authentication scheme.
> This BIP does not
> 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
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> BIP150]</ref>.
>
> An attacker could delay or halt v2 protocol enforcement by providing a
> reasonable amount of peers not supporting the v2 protocol.
>
> == Compatibility ==
>
> This proposal is backward compatible (as long as not enforced).
Kudos for making this second attempt backward compatible.
> Non-supporting
> peers can still use unencrypted communications.
>
> == Reference implementation ==
> * Complete Bitcoin Core implementation:
> https://github.com/bitcoin/bitcoin/pull/14032
> * Reference implementation of the AEAD in C:
> https://github.com/jonasschnelli/chacha20poly1305
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190324/87025ec1/attachment.sig>;