To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <57A89EA3.4020101@jonasschnelli.ch>
From: Andy Schroder <info@AndySchroder.com>
Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Message-ID: <57A8BCD9.7050402@AndySchroder.com>
Date: Mon, 8 Aug 2016 13:09:45 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8"
Subject: Re: [bitcoin-dev] Authentication BIP
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8
Content-Type: multipart/mixed; boundary="Cx5JA03uek1dMBS2UTJ6VRfVCad5BN8k5"
From: Andy Schroder <info@AndySchroder.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57A8BCD9.7050402@AndySchroder.com>
Subject: Re: Authentication BIP
References: <57A89EA3.4020101@jonasschnelli.ch>
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>

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

On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a=

> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.


I have mixed feelings about strictly tying the identity-public-keys with =

a network identifier. I think the purpose of this is to detect if=20
someone has physically stolen and compromised my bitcoin node and placed =

it on another network under control of an attacker. This seems to be a=20
bit of a benefit, however, an attacker could always spoof the original=20
network identifier anyway.

I run my bitcoin node on an internet connection that does not guarantee=20
a static IP address (although it usually stays the same for several=20
weeks or months at a time). I'd like to be able to make secure=20
connections back to my own node, even if I know the IP address may=20
change from time to time. There are several reasons for wanting to this=20
with a changing IP. The first is because the bandwidth on my internet=20
connection with a guaranteed static IP address is considerably more=20
expensive than my internet connection without a guaranteed static IP=20
address. The second reason is because the DNS PTR record for my static=20
IP address is personally identifiable based on other reasons/services.=20
The internet connection that my bitcoin node is using without a=20
guaranteed static IP address just has a PTR record that basically=20
includes my IP address and ISP name. This isn't much use to the general=20
public (although my ISP obviously knows who I am). The third reason is=20
that I consider it a good thing from a privacy perspective if my IP=20
address changes every once and a while.

Maybe a strict check option where the identity-public-keys must=20
optionally match a specific network identifier would be a compromise?=20
Maybe this is up to the client implementation to decide, so it should=20
just be suggested in the BIP rather than required?


> # ___authorized-peers___ contains authorized identity-public-keys

Is there an option for a wildcard here? Couldn't there be a case where=20
the client wants to authenticate, but the bitcoin node does not care who =

it's clients are? This would be similar to many of the http based=20
bitcoin block explorer API services that are out there. The API=20
operators have built up some reputation, so people use them, but they=20
don't necessarily care about who their users are.


> =3D=3D=3D Local identity key management =3D=3D=3D
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).

What if I have bitcoind listening on multiple IPv4 interfaces? Can I=20
have a different identity-key for each IPv4 interface?

Also, would it be possible to only allow this authentication on specific =

interfaces? In my example above where I have two internet connections,=20
if you don't agree to loosening the tie between the network identifier=20
and the identity-public-keys, maybe I would just connect my bitcoin node =

to both internet connections, but only allow a few authorized-peers on=20
the static IP (which would be low bandwidth), and then not authenticate=20
on the internet connection with the changing IP at all

If you don't want to increase complexity by adding these options, one=20
could always accomplish the same thing by runing two instances of=20
bitcoind and pairing the two over a local network, it would just be a=20
waste of resources.


> =3D=3D Disadvantages =3D=3D
>
> The protocol may be slow if a peer has a large authorized-peers databas=
e
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.


Does openssh have this same problem?

I'm assuming this could be parallelized very easily, so it is not a huge =

problem?


--Cx5JA03uek1dMBS2UTJ6VRfVCad5BN8k5--

--mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8
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)

iQEcBAEBAgAGBQJXqLzZAAoJEDT679stRBhrd8sH+gLi50vb/nY4p4QRtoSHt9Q1
oJs7epIYM1/CAiEht5JhfSSSQDd8b7qlx1pShu9wgzTODqq2VR+Thz3MD1f2BIkW
KUHUL+xikIaBsXITRKxhRqpu/etm4/MZiJJKJ+KukCvMsY5R5e4CszTs5Zgadd7V
HRrdMy9aOWOcmBwr31DU1t0yE3XssUm1sRQ8YWxsrr928oxvVyilev4+rXGCdsEl
OKDCWc03MH4EYqhNemezb0fYekpdIHbqgyWAapbdHGlW6onUFWioIC4Cgh/3Chln
SzvHXjqoQo9YPoR3n0BhexBV+490O/r6OBZvJz9rLnGppjdf0RzEtqIWRqqzrac=
=K+i4
-----END PGP SIGNATURE-----

--mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8--