1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1X9K3S-00043f-UR
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Jul 2014 20:19:27 +0000
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;
Received: from mail-lb0-f174.google.com ([209.85.217.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X9K3R-0007Ey-OJ
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Jul 2014 20:19:26 +0000
Received: by mail-lb0-f174.google.com with SMTP id c11so5213161lbj.33
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Jul 2014 13:19:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.16.230 with SMTP id j6mr6084521lbd.90.1405973959127;
Mon, 21 Jul 2014 13:19:19 -0700 (PDT)
Received: by 10.112.35.138 with HTTP; Mon, 21 Jul 2014 13:19:19 -0700 (PDT)
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
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1X9K3R-0007Ey-OJ
Cc: kevin <bit.kevin@gmail.com>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Policy for DNS seeds
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 20:19:27 -0000
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)
|
