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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1Vy6pQ-0003bC-ST
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Dec 2013 21:26:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1Vy6pP-0000YD-Ev for bitcoin-development@lists.sourceforge.net;
Tue, 31 Dec 2013 21:26:20 +0000
Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
mail.taplink.co ; Tue, 31 Dec 2013 13:29:39 -0800
Content-Type: multipart/alternative; boundary=----------8ki5oSGSxSxTmxfFaTZ5nI
To: "Gregory Maxwell" <gmaxwell@gmail.com>, "Mike Hearn" <mike@plan99.net>
References: <52A3C8A5.7010606@gmail.com>
<1795f3067ba3fcdd0caf978cc59ff024.squirrel@fruiteater.riseup.net>
<52A435EA.7090405@gmail.com> <201312081237.24473.luke@dashjr.org>
<CANAnSg2OrmQAcZ+cZdtQeADicH3U29QOgYPfP1AQhOMP6+P1wg@mail.gmail.com>
<CAAS2fgR0khyJxmz9c2Oc87hOFgiNuiPJuaeugGajdo_EcKEW9w@mail.gmail.com>
<20131212205106.GA4572@netbook.cypherspace.org>
<CANAnSg3nPhrk2k=yDKf39AuBQnSuTWJbgANdMhGe=soiOy0NTw@mail.gmail.com>
<CAAS2fgTmWRMxYweu3sNn_X7grgjUqTQujM-DbZRxG_YMZnD=7g@mail.gmail.com>
<CANEZrP2X_63qkuNuk0MvsLR9ewd7HR0mPVaD7bZSgWMTJ5-9FQ@mail.gmail.com>
<CAAS2fgQmMZ6RYjbJ6ZfFO5+ZhZoR4d4yMf8CXLXKPmZt3-Je4Q@mail.gmail.com>
<CANEZrP1mdJNa7ADkUXTGDNKMSCROjGAVbMXZXxodxCz1LFDzZw@mail.gmail.com>
Date: Tue, 31 Dec 2013 13:25:40 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <CANEZrP1mdJNa7ADkUXTGDNKMSCROjGAVbMXZXxodxCz1LFDzZw@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -0.7 (/)
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 SPF_PASS SPF: sender matches SPF record
-0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Vy6pP-0000YD-Ev
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org,
your thoughts?
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: Tue, 31 Dec 2013 21:26:21 -0000
------------8ki5oSGSxSxTmxfFaTZ5nI
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
I didn't know about the dedicated server meltdown, it wasn't any of my
infra. Anyway, my previous offer still stands.
One less 'security theater' approach would be if we could provide
forward-validation of updates using the blockchain. It's always going to
be up to the user the first time they install the wallet to verify the
provenance of the binaries/source. From that point forward, we could make
it easier if the wallet could detect updates and prove they were valid.
This could be as simple as hard-coding a public key into the client and
checking a signature on the new binaries. But it could also be more
interesting...
For example, a well known address on the blockchain corresponds to
multi-sig with keys controlled by developers (or whatever key policy the
release team wants to impose). A spend from that address announces a new
release, and includes the expected hash of the file.
You would probably need some way to handle the different release targets.
A more rigorous approach could identify all the various releases in terms
of a BIP32 xpubkey whose branches would correspond to the different
release trains and platform builds. Spends from a node announce the
release and the expected hash.
This provides zero benefit if the wallet software is already compromised,
but I think this would allow trusted automatic update notification, and a
trusted way to deliver the expected hashes. It also might resolve some of
the consternation around when a release is truly "released", if that's
really a problem.
I'm not sure how far along the slope you would want to go; 1) announcing
updates in the UI, 2) providing a button the user could click to verify a
binary matches its expected hash, 3) click to download and verify the
upgrade matches the expected hash, 4) click to upgrade
Formalizing the release process around a set of privkeys (or split shares
of keys) may raise its own set of questions.
For the download itself, I've heard the advocates of announcing
availability on the blockchain leading to a BitTorrent magnet link, but I
also understand objections to adding an entire BitTorrent stack into a
wallet.
On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99.net> wrote:
>> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>
> Oh, it did? When was that? I must have missed this excitement :)
>Any idea how much load it had?
>
>> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS
> pretty hard, and saying that based on the access to the source docs some
> of >their MITM attacks can't beat TLS. It appears that they have the
> capability to do bulk MITM and rewrite of downloads as Drak says but
> *not* when >TLS is present, that would force more targeted attacks. So
> to me that implies that TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then
> that'd be an issue. We could consider hosting downloads on AppEngine or
> >something else that can handle both high load and TLS.
------------8ki5oSGSxSxTmxfFaTZ5nI
Content-Type: multipart/related; boundary=----------8ki5oSGSxSxTmxxnfxpXDG
------------8ki5oSGSxSxTmxxnfxpXDG
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1388525140450.a3fd577e5d6b3eec@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body><div>I didn't know about the dedicated server meltdown, it wasn't =
any of my infra. Anyway, my previous offer still stands.</div><div><br><=
/div><div>One less 'security theater' approach would be if we could prov=
ide forward-validation of updates using the blockchain. It's always goin=
g to be up to the user the first time they install the wallet to verify =
the provenance of the binaries/source. From that point forward, we could=
make it easier if the wallet could detect updates and prove they were v=
alid.</div><div><br></div><div>This could be as simple as hard-coding a =
public key into the client and checking a signature on the new binaries.=
But it could also be more interesting...</div><div><br></div><div>For e=
xample, a well known address on the blockchain corresponds to multi-sig =
with keys controlled by developers (or whatever key policy the release t=
eam wants to impose). A spend from that address announces a new release,=
and includes the expected hash of the file.</div><div><br></div><div>Yo=
u would probably need some way to handle the different release targets. =
A more rigorous approach could identify all the various releases in term=
s of a BIP32 xpubkey whose branches would correspond to the different re=
lease trains and platform builds. Spends from a node announce the releas=
e and the expected hash.</div><div><br></div><div>This provides zero ben=
efit if the wallet software is already compromised, but I think this wou=
ld allow trusted automatic update notification, and a trusted way to del=
iver the expected hashes. It also might resolve some of the consternatio=
n around when a release is truly "released", if that's really a problem.=
</div><div><br></div><div>I'm not sure how far along the slope you would=
want to go; 1) announcing updates in the UI, 2) providing a button the =
user could click to verify a binary matches its expected hash, 3) click =
to download and verify the upgrade matches the expected hash, 4) click t=
o upgrade</div><div><br></div><div>Formalizing the release process aroun=
d a set of privkeys (or split shares of keys) may raise its own set of q=
uestions.</div><div><br></div><div>For the download itself, I've heard t=
he advocates of announcing availability on the blockchain leading to a B=
itTorrent magnet link, but I also understand objections to adding an ent=
ire BitTorrent stack into a wallet.</div><div><br></div><div>On Tue, 31 =
Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99.net> wrote:<br></=
div><br><blockquote style=3D"margin: 0 0 0.80ex; border-left: #0000FF 2p=
x solid; padding-left: 1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The site wa=
s actually moved onto a dedicated server temporarily and it<br>
melted down under the load. I wouldn't call that no progress.<br></block=
quote><div><br></div><div>Oh, it did? When was that? I must have missed =
this excitement :)</div><div> </div><div>Any idea how much load it =
had?<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Perhaps I wasn't =
clear on the point I was making Drak's threat model<br>
is not improved in the slightest by SSL. It would be improved by<br>
increasing the use of signature checking, e.g. by making it easier.<br><=
/blockquote><div><br></div><div>Well, that depends. If you watch Appleba=
ums talk he is pushing TLS pretty hard, and saying that based on the acc=
ess to the source docs some of their MITM attacks can't beat TLS. It app=
ears that they have the capability to do bulk MITM and rewrite of downlo=
ads as Drak says but *not* when TLS is present, that would force more ta=
rgeted attacks. So to me that implies that TLS does raise the bar and is=
worth doing.</div>
<div><br></div><div>However if we can't find a server that won't melt un=
der the load, then that'd be an issue. We could consider hosting downloa=
ds on AppEngine or something else that can handle both high load and TLS=
.</div>
</div></div></div>
</blockquote><br><br><br></body></html>
------------8ki5oSGSxSxTmxxnfxpXDG--
------------8ki5oSGSxSxTmxfFaTZ5nI--
|
