Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.174 as permitted sender)
	client-ip=209.85.217.174; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <20140721192401.GA16764@petertodd.org>
References: <CA+s+GJA1aLqOamoYTHRNsF3bGb=pKwNHXGYzQ6GSTgQnic+yCA@mail.gmail.com>
	<20140721192401.GA16764@petertodd.org>
Date: Mon, 21 Jul 2014 13:19:19 -0700
Message-ID: <CAAS2fgQsq9AdAsZ09nbU9j2r=atL4KUuNNUYuc+ZTPKJLXScWQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: kevin <bit.kevin@gmail.com>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Policy for DNS seeds
Precedence: list

On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd <pete@petertodd.org> wrote:
> Might be worthwhile to also write an "Expectations for DNSSeed users"
> outlining what security properties the seeds actually have, and what
> kind of attacks are possible.

Agreed.  I've seen some amount of use of dnsseeds which I would
consider inadvisable considering their weakness.

> Many users would be better served with
> seeds that offer authenticated and encrypted connections to the seeds
> for instance. (esp. if they're using authed/encrypted connections to
> nodes, e.g. Tor hidden services)

Also agreed, we ought to have a separate onionseed process for hosts
which can reach hidden services which would be inherently
authenticated and somewhat more anonymous. The existing introduction
method already doesn't work well for onlynet=3Donion hosts, so that
would be a good place to start.

>> 1. The DNSseed results must consist exclusively of fairly selected and
>> functioning Bitcoin nodes from the public network to the best of the
>> operators understanding and capability.
>
> Along the lines of my above point, for Bitcoin Core users of the
> DNSSeeds what constitutes a "functioning" Bitcoin node is much more
> broad than what other users might need.

I was deliberately vague here in that I'm trying to avoid foreclosing
reasonable activities like omitting nodes which are uselessly slow,
diverged from the network, or running very old software.  The test I'm
suggesting is that if "why am I doing this" is "to connect users to
functioning nodes" then it's probably okay, but if its to achieve some
other end=E2=80=94 probably not.

> Note that singling out a group of hosts to receive different results
> with DNS is especially difficult as you'll be usually singling out
> different ISP's rather than hosts themselves. That said if we ever start
> operating HTTPS or similar seeds this expectation will become even more
> relevant for them.

Yes, this is one of the reasons we use DNS (and also one of the
reasons the document suggests a non-zero minimum ttl)... but belt and
suspenders, even though technical measures are protective here it's
good to make it clear that this isn't acceptable.

> While there have been
> suggestions to use the testnet seeds for testing vulnerabilities, the
> public discussion clause should suffice to allow those exceptions.

Yep. That was the intent. (well not testnet, but the notion that if
there really were a good reason to do something else a discussion
should cover it)