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 49C79412 for ; Mon, 8 Aug 2016 17:54:57 +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 84D78276 for ; Mon, 8 Aug 2016 17:54:56 +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 A52052345956D; Mon, 8 Aug 2016 13:54:55 -0400 (EDT) To: Gregory Maxwell , Bitcoin Protocol Discussion References: <57A89EA3.4020101@jonasschnelli.ch> <57A8BCD9.7050402@AndySchroder.com> From: Andy Schroder Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Message-ID: <57A8C76D.1080405@AndySchroder.com> Date: Mon, 8 Aug 2016 13:54:53 -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: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU" 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:54:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU Content-Type: multipart/mixed; boundary="NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3" From: Andy Schroder To: Gregory Maxwell , Bitcoin Protocol Discussion Message-ID: <57A8C76D.1080405@AndySchroder.com> Subject: Re: [bitcoin-dev] Authentication BIP References: <57A89EA3.4020101@jonasschnelli.ch> <57A8BCD9.7050402@AndySchroder.com> In-Reply-To: --NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 08/08/2016 01:42 PM, Gregory Maxwell wrote: > On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev > wrote: >> I have mixed feelings about strictly tying the identity-public-keys wi= th a > [...] >> guaranteed static IP address. The second reason is because the DNS PTR= > I don't see any reason that it couldn't also accept a DNS name there. > > The purpose of that table is so the client knows which server ID to exp= ect. Okay, that may be fine. You are saying otherwise you'd have to do a=20 trial and error and this tying to a network identifier just speeds=20 things up? If the DNS is spoofed, it's no big deal because the=20 authentication will fail anyway? > >> I consider it a good thing from a privacy perspective if my IP address= >> changes every once and a while. > And the design seeks to preserve that privacy. > >> Maybe a strict check option where the identity-public-keys must option= ally >> match a specific network identifier would be a compromise? Maybe this = is up > The client must know the identity of the server it is expecting. The > server does not announce itself. If it did then your changing of IPs > would provide you with no privacy at all. Good point. > > If the design is to provide any protection against MITM you need to > know who you expected to connect to in any case. > >> I think the purpose of this is to detect if someone has physically sto= len and compromised my bitcoin node and placed it on another network unde= r control of an attacker. > Huh. No. Almost the opposite. The system is designed to inhibit > fingerprinting. You can't tell what identity key(s) a node has unless > you already know them. This means that if you don't publish your node > pubkey, no one can use it to track your node around the network. Cool. > >> Is there an option for a wildcard here? Couldn't there be a case where= the >> client wants to authenticate, but the bitcoin node does not care who i= t's >> clients are? This would be similar to many of the http based bitcoin b= lock >> explorer API services that are out there. The API operators have built= up >> some reputation, so people use them, but they don't necessarily care a= bout >> who their users are. > Then they're just not listed in the file. The client can ask the server= to > authenticate without authenticating itself. Simple enough. > >> Does openssh have this same problem? > No. OpenSSH doesn't make an effort to protect the privacy of its users.= > >> I'm assuming this could be parallelized very easily, so it is not a hu= ge >> problem? > It's not a issue because we're not aware of any usecase where a node > would have a large list of authenticated peers. > >> Each peer can configure one identity-key (ECC, 32 bytes) per listening= > network interface (IPv4, IPv6, tor). > > I'm not aware of any reason for this limitation to exist. A node > should be able to have as many listening identities as it wants, with > a similar cost to having a large authorized keys list. > So you are saying that you agree with me that the original text needs to = be revised slightly or I am just misinterpreting the original text? --NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3-- --nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU 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) iQEcBAEBAgAGBQJXqMdtAAoJEDT679stRBhrgF4IANCRJ5+ZFZqH84pL9nrBoaxv 5QVoEAKqBSAezm9PMlEqJ1EeP5Nt2B4dU2OcgUy4qqv6xTSCshPHasAZ5THrgpaf uo1yJwTGx9eLEdAaBPuNxJETqmNLphLYxXrC27lUj5H59HXK9CQ/2+EwOp5P4kin YkrGJgYdm+gMfu6UvRfs7J/wXL5tipLgIPEEBE3466j23AP5iPpnXY7qn9CbNytI mPCbp+iLjJYgLAmujonCn/558SwTo2wHIQ5XVAMVOCZQnnlw9Ij1bGrYCGXD34Gw hjAa1QuwJJ/cajzE3yp9461uQ06LZPbiN0FkD4ylbkim0I0eUfa0zLeuNLJVeDE= =H9sn -----END PGP SIGNATURE----- --nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU--