To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <57A89EA3.4020101@jonasschnelli.ch>
	<57A8BCD9.7050402@AndySchroder.com>
	<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
From: Andy Schroder <info@AndySchroder.com>
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: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU"
Subject: Re: [bitcoin-dev] Authentication BIP
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nHQTGVGvtWieScs5jMAjcDcGvJGD8FkeU
Content-Type: multipart/mixed; boundary="NWV5mNGVtfFNRD7w98AcQ9aLe21ABXlq3"
From: Andy Schroder <info@AndySchroder.com>
To: Gregory Maxwell <greg@xiph.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <57A8C76D.1080405@AndySchroder.com>
Subject: Re: [bitcoin-dev] Authentication BIP
References: <57A89EA3.4020101@jonasschnelli.ch>
 <57A8BCD9.7050402@AndySchroder.com>
 <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
In-Reply-To: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>

--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
> <bitcoin-dev@lists.linuxfoundation.org> 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--