To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <56F51026.8010708@jonasschnelli.ch>
Date: Fri, 25 Mar 2016 11:17:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
	Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="Xjq71CSRInxAr51uMdcalB0f29ap1f8DP"
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Xjq71CSRInxAr51uMdcalB0f29ap1f8DP
Content-Type: multipart/mixed; boundary="rlted09gewTUMsnajOEVsc3ldwH7EVVkf"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <56F51026.8010708@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
References: <56F2B51C.8000105@jonasschnelli.ch>
In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch>

--rlted09gewTUMsnajOEVsc3ldwH7EVVkf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362

Thanks for the feedback and IRC discussions.

I have overhauled both BIPs.
https://github.com/bitcoin/bips/pull/362/files#diff

Main changes for the encryption BIP:
* No message wrapping. Once encryption is established, everything is
encrypted. No timeout.
* Added MAC: proposed AEAD is now ChaCha20-Poly1305 with an alternative
for AES256-GCH
* Independent ECDH negotiation and independent secrets for the symmetric
cipher for both communication directions
* Optimized message format and message-batch-option for encrypted data

It could be that the p2p performance for Chacha20-poly1305 encrypted
message is slightly better then the current plaintext message format
(dropping the network magic and the sha256 per message).

P2p authentication BIP:
* No message wrapping. Peers keep the state once authenticated.
* Simplified and auth now requires encrypted channels.


Some answers...

> How does a peer know what messages the other peer requires to be
authenticated?

This is not covered by the auth BIP. Peers could agree on a protocol
extension outside of any BIP.
Once auth is possible, new BIPs could be written. Things like only
allowing filtering (or other services) to authenticated peers (and
disabling NODE_BLOOM).

> How does banning in this specific case enable fingerprinting as
opposed to any other banning?

Current nodes ignore a unknown message with a command like "auth".
Banning would allow a requesting peer to identify nodes that support
auth and attack them over different channels ("ah, ... this guy supports
auth, they must have some secret data, lets attack over SSH).

>> This proposal is backward compatible. Non supporting peers will
ignore the <code>auth</code> message.
> ... and not process it at all? How is that backward compatible?

Depends how we define backward compatibility. :-)
Peers supporting this "extension" can still interact with older peers.

> This proposal is backward compatible. Non supporting peers will ignore
the > <code>enc*</code> messages.

Current p2p implementation ignores any unknown command.


</jonas>


--rlted09gewTUMsnajOEVsc3ldwH7EVVkf--

--Xjq71CSRInxAr51uMdcalB0f29ap1f8DP
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

iQIcBAEBCAAGBQJW9RAmAAoJECnUvLZBb1PsjnUQAKmyYMzhtU6rQj1nnwiumxEf
m4CPZyShbbIC6AWh7+TnMwAqq9Rg2hU2l72T2i/OWWTRODPnNf9D5BwqdJ9kit02
61xdzXqgbZzk4rzT7AgiMJVXyVXzTXmeV+MvIuqvDKiTYcA0pv8RGh3SlXgqlIAC
OM7+dMuUu1cUABslv9O1P+NWCzWle5CITC6wnHR9ktwwTEsBuzYlAM6EtJqCaDTe
UYmGgKvdUhRfpjQ/mhnEQYyKj7k0tlvmozco7chUt3caCgSQIjsaznNlGw5bMAqx
Lefr8gPE5tCaZuHZLuU31pQLDiVCGVLRDzeAtnJUitqGIiDnv22aqLZHi9AoLbWc
h0pDoCXCleIHRMz4c68j/672Fjg3JYL1xe2M1C3YgfWx2guxKjdgZcF6TcEKAg7/
aFO43/5nvh/WkfF8jgBB9Y+TMa69nuTd50HCwQVbsTIHS1lRYn1F+OxYRrUPZ3hG
NS9CqVi2wbBa9YjOpMRCzpgNX9AuBze4ZjWbjxPk5KG9h9+h2B7BUpmdtACaRG8E
obboRoRrcbOGUIy0Ba2ESLHIzILPsyS8U0oHDp/I1jiVWexM2ULi7KKfhUuRAB//
GaoRC7eMbKq9ohpFBGvqnQ/RQt15iktGt10JPmz6lCM6VO1qCuX1VfgUj3op3esI
8yOswqm+ODhaCf53tmlB
=r+/N
-----END PGP SIGNATURE-----

--Xjq71CSRInxAr51uMdcalB0f29ap1f8DP--