path: root/d4/fbf7a7ab0b5c5c610805b888b45e9963bdad22

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 716B040C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 14 Feb 2017 20:59:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 42BBEF4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 14 Feb 2017 20:59:15 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
	id 402EC2E6010C; Tue, 14 Feb 2017 21:59:14 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
	autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch
	[87.102.140.182]) by server3 (Postfix) with ESMTPSA id BF2352D0022C;
	Tue, 14 Feb 2017 21:59:10 +0100 (CET)
To: Eric Voskuil <eric@voskuil.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	libbitcoin@lists.dyne.org
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
	<CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
	<dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
	<ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch>
	<638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
	<e153823d-e38e-b4b6-01d5-b9d981381e01@jonasschnelli.ch>
	<17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <2c059f3c-620e-4324-0726-4c56dfab0b43@jonasschnelli.ch>
Date: Tue, 14 Feb 2017 21:58:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
	Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs"
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
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: Tue, 14 Feb 2017 20:59:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs
Content-Type: multipart/mixed; boundary="GdxnCHx1xPlPL9QlNl1p9nIdW7w9wkx3s";
 protected-headers="v1"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Eric Voskuil <eric@voskuil.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 libbitcoin@lists.dyne.org
Message-ID: <2c059f3c-620e-4324-0726-4c56dfab0b43@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP151 protocol incompatibility
References: <ba422d5e-8e96-3475-2a29-80d89fd67322@voskuil.org>
 <CAPg+sBhDjVuN6=tdvUcSY5OCdJD7s3Jp90K1qx0iRX+2WppUQQ@mail.gmail.com>
 <dde5349d-c430-ad57-30c7-77954ff1a94d@voskuil.org>
 <ff7c24ba-7c70-efaf-a319-b1aebfd8a3bd@jonasschnelli.ch>
 <638deacd-c117-f1a7-10de-a7e36a47c3c7@voskuil.org>
 <e153823d-e38e-b4b6-01d5-b9d981381e01@jonasschnelli.ch>
 <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org>
In-Reply-To: <17f2f92c-68fc-7a7d-c015-9bad810365e3@voskuil.org>

--GdxnCHx1xPlPL9QlNl1p9nIdW7w9wkx3s
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


>> This indeed is not ideal for compatibility checks, but increases secur=
ity.
> The issue I raised is that it is not backward compatible. It sounds lik=
e
> you agree but consider it a fair trade. My suggesting was that the BIP
> be updated to reflect the lack of compatibility.
It's still backward compatible. All (?) SPV clients and full node
implementation would still work if BIP151 has been implemented.
Isn't that backward compatibility?
>> I could not find a protocol specification that said communication must=

>> be terminated when messages are transmitted before the version handsha=
ke
>> has been done.
> It doesn't need to be specified, most of Bitcoin is unspecified. The
> version handshake establishes the negotiated version. It is not possibl=
e
> to determine if a message is of the negotiated version before the
> version is negotiated. All messages apart from this one have followed
> that rule.
Yes. But encryption negotiation must be done before the version
handshake (security).
>
>> Also. BIP151 clearly says that the requesting peer needs to initiate t=
he
>> encryption (encinit).
> An incoming connection will be dropped due to invalid protocol and
> potentially banned depending on the implementation.
This is not true. If the connecting peer (assume the SPV client) will
not request encryption, the responding peer (the node) will not enforce
or ask for encryption.
This is clearly written in the BIP.
>> It could very likely be possible that the initial responding peer trie=
s
>> to initiate a encryption session which would mean that BIP151 was not
>> implemented correctly.
>> Correct me if I'm wrong please.
> I did consider the possibility, but there's this:
>
> "Encryption initialization must happen before sending any other message=
s
> to the responding peer (encinit message after a version message must be=

> ignored)."
>
> https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#specific=
ation
>
> The BIP does not define "responding" and "requesting" peers, but:
>
> "A peer that supports encryption must accept encryption requests from
> all peers... The responding peer accepts the encryption request by
> sending a encack message."
>
> This implies the requesting peer is the peer that sends the message. Yo=
u
> seem to be saying that the requesting peer is the one that initiated
> the connection and the responding peer is the connection receiver. If
> this is the case it should be more clearly documented. But in the
> case I experienced the "requester" of an encrypted session was also
> the "receiver" of the connection.
I think the BIP makes this very clear. IMO you are trying to hide your
standpoint behind a wired interpretations of the BIP.

=46rom the BIP:
=C2=ABTo request encrypted communication, the requesting peer generates a=
n EC
ephemeral-session-keypair and sends an encinit message to the responding
peer and waits for a encack message. The responding node must do the
same encinit/encack interaction for the opposite communication direction.=
=C2=BB

This seems to be pretty clear to me. You can interpret the "requesting
peer" and "responding peer" per message interaction. But then the whole
BIP would make no sense.

I'm happy if you can do a PR on the BIP that makes the wording better.
This would actually be a productive step.
>
>>>> Or do I make a mistake somewhere?
>>> Yes, the ordering of the messages. New messages can only be added aft=
er
>>> the handshake negotiates the higher version. Otherwise the handshake =
is
>>> both irrelevant (as Pieter is implying) and broken (for all existing
>>> protocol versions).
>> I could not find evidence of the protocol specification that would
>> forbid (=3Dterminate connection) such messages and I think allowing
>> unknown-messages before the version handshake makes the protocol flexi=
ble.
> Flexible is certainly one word for it. Another way to describe it is
> dirty. Allowing invalid messages in a protocol encourages protocol
> incompatibility. You end up with various implementations and eventually=

> have no way of knowing how they are impacted by changes. There could be=

> a range of peers inter-operating with the full network while running
> their own sub-protocols. Given the network is public and strong
> identification of peers is undesirable, the invalid messages would
> reasonably just get sent to everyone. So over time, what is the
> protocol? Due to certain "flexibility" it is already a hassle to
> properly implement.
Then you would have to go after all BIPs deployed this way. This
argument has nothing to do with BIP151 it questions the whole new
protocol features deployment.
Again, check this code part:

https://github.com/bitcoin/bitcoin/blob/a06ede9a138d0fb86b0de17c42b936d9f=
e6e2158/src/net_processing.cpp#L2595


>
>> Are there any reasons we should drop peers if they send us unknown, bu=
t
>> correctly formatted p2p packages (magic, checksum, etc.) before the
>> version handshake, ... but not drop them if we have received unknown
>> messages after the version handshake?
> There is no reason to treat invalid messages differently based on where=

> they occur in the communication. After the handshake the agreed version=

> is known to both peers. As a result there is never a reason for an
> invalid message to be sent. Therefore it is always proper to drop a pee=
r
> that sends an invalid message.
That's up to the implementation. But the current flexibility exists
because we not drop.
Again, see above.
>> I can't see that a such spec. would reduce the DOS attack vector?
> This was previously addressed (immediately below).
No. I'd like to hear from you why the DOS attack vector would be larger
if the encryption neg. would be after the version handshake.
>
>>>>> As for DOS, waste of bandwidth is not something to be ignored. If a=
 peer
>>>>> is flooding a node with addr message the node can manage it because=
 it
>>>>> understands the semantics of addr messages. If a node is required t=
o
>>>>> allow any message that it cannot understand it has no recourse. It
>>>>> cannot determine whether it is under attack or if the behavior is
>>>>> correct and for proper continued operation must be ignored.
>>>> How do you threat any other not known message types?
>>> You may be more familiar with non-validating peers. If a message type=
 is
>>> not known it is an invalid message and the peer is immediately droppe=
d.
>>> We started seeing early drops in handshakes with bcoin nodes because =
of
>>> this issue.
> Yes, this is the purpose of version negotiation, which is why there are=

> version and verack messages. And this is also why, in the satoshi
> client, two of the above messages are sent from the verack handler. The=

> feefilter message is sent dynamically but only if the peer's version
> allows it.

Again. Encryption =E2=80=93 for the sake of security =E2=80=93 must be th=
e first
interaction.
This is exceptional for BIP151 and I'd like to hear the real downsides
of doing that.
>
>> You can't link a (unimplemented) specification (improvement process) t=
o
>> a protocol version before deployment. Or can you?
> I'm not sure I follow your question. The BIP should presumably declare =
a
> version number if one is necessary.
What? You want to define protocol version number in draft improvement
specifications?
How should that be possible?
It's like defining a new HTML version number if you propose/draft a new
video streaming format.


</jonas>


--GdxnCHx1xPlPL9QlNl1p9nIdW7w9wkx3s--

--C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlijb5oACgkQKdS8tkFv
U+xk3g/+M+S9G5XmYl1HzveOHDbtg3oGgHhBHnndIfDOfdcP1NRgCiHdiOFQfzSR
ewAl5uEcE1j0Vscd25N70L+rI/jbUWT+814+j5Rvy+j8afW6OHGsG712WkDt219H
/Z0tUNL1+gVDh8qwTCxv0QhHhsf/SS/gsDqJdS1QjIdKYm78mQWuQXyGv/OnoO7c
1mXEOnXGWpETH1AYV8is8eHN22XMJHT9G/Pt3GFJFGzjsfFRZpvcUVpqgSlfnoYN
EEBbyUORANcT1uGejCUoZ5hhqixeiW3DfXQrhJMgnfb/cP/08T2zXuoXV2gu4sf5
yflY8EDMK4QYn6d2xcpsVi/gItUa7SBtMnXPbUTruHnc3xC3Qv58okKEI/p83PV0
/MJ2W9MNynjbWRkDMRX60FJkIQv+eCTDFI+IVrcpvf42anxxLSCK3MW4Armrtyeu
UEL/rKkCKilsdxAETRqsJ29Ty+qXZUZ5g1woybK7292Ikdbek3xAfb9BZTU/I4bV
ttRt+B3wzpZLg7LX1kIESFHqGCkJuptHeOaB7tfzZ7Q6pxGb11qBixz9MvIH3RoN
btZ+hjYjs/Fb8SdJAv9z4K1c3cVwadA20TmlLZGx/ROholPx0dvIduFeWSJE6aGm
TA4ACZfHeVC4xuMt41kY6y4uqWhG6iZ2ah+Ozq+NM6BoL+vPaA4=
=bL43
-----END PGP SIGNATURE-----

--C20EkEHwx3fuv7xSkACFUJGacxpsGlrSs--