From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F3D62412 for ; Mon, 8 Aug 2016 17:09:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from uschroder.com (uschroder.com [74.142.93.202]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A699F270 for ; Mon, 8 Aug 2016 17:09:49 +0000 (UTC) Received: from [192.168.253.4] (cpe-96-28-21-149.kya.res.rr.com [96.28.21.149]) by uschroder.com (Postfix) with ESMTPSA id 6AA842345936B; Mon, 8 Aug 2016 13:09:48 -0400 (EDT) To: Bitcoin Protocol Discussion References: <57A89EA3.4020101@jonasschnelli.ch> From: Andy Schroder 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" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Authentication BIP X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 17:09:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mJoadm8Wc8NiQDt69qEpVHDU50UKvxBE8 Content-Type: multipart/mixed; boundary="Cx5JA03uek1dMBS2UTJ6VRfVCad5BN8k5" From: Andy Schroder To: Bitcoin Protocol Discussion Cc: Jonas Schnelli 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--