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
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
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 <mh.in.england@gmail.com>) id 1VyNQy-0005AA-32
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Jan 2014 15:10:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.180 as permitted sender)
client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f180.google.com;
Received: from mail-ob0-f180.google.com ([209.85.214.180])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VyNQw-0007St-S4
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Jan 2014 15:10:12 +0000
Received: by mail-ob0-f180.google.com with SMTP id wo20so13384309obc.25
for <bitcoin-development@lists.sourceforge.net>;
Wed, 01 Jan 2014 07:10:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.213.166 with SMTP id nt6mr10055541obc.53.1388589005372;
Wed, 01 Jan 2014 07:10:05 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.95.200 with HTTP; Wed, 1 Jan 2014 07:10:05 -0800 (PST)
In-Reply-To: <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.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>
<op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net>
Date: Wed, 1 Jan 2014 15:10:05 +0000
X-Google-Sender-Auth: JsIT5RuE5cLuJY2NbiUqmu1pEeQ
Message-ID: <CANEZrP3DmATBpi_SNS2R98R2Lf3cfuYK3dE_6yCwTL-MgYpHLg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=001a11c2e60a6782a804eeea129b
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1VyNQw-0007St-S4
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: Wed, 01 Jan 2014 15:10:12 -0000
--001a11c2e60a6782a804eeea129b
Content-Type: text/plain; charset=UTF-8
That seems overly complicated, there's no need for the Bitcoin protocol to
be involved. Deterministic builds with threshold signed updates are a
problem the entire crypto community is now interested in solving - any
solution should be generic.
Really all you need is an update engine that allows a CHECKMULTISIG type
approach. When the update engine is not under our control, i.e. on Android,
Shoup style RSA threshold signatures can potentially work (though I must
admit, I have never found time to play with the implementation I have for
that algorithm).
On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> 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.
>
>
>
>
>
--001a11c2e60a6782a804eeea129b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That seems overly complicated, there's no need for the=
Bitcoin protocol to be involved. Deterministic builds with threshold signe=
d updates are a problem the entire crypto community is now interested in so=
lving - any solution should be generic.<div>
<br></div><div>Really all you need is an update engine that allows a CHECKM=
ULTISIG type approach. When the update engine is not under our control, i.e=
. on Android, Shoup style RSA threshold signatures can potentially work (th=
ough I must admit, I have never found time to play with the implementation =
I have for that algorithm).</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><u></u>
<div><div>I didn't know about the dedicated server meltdown, it wasn=
9;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 coul=
d provide forward-validation of updates using the blockchain. It's alwa=
ys going to be up to the user the first time they install the wallet to ver=
ify the provenance of the binaries/source. From that point forward, we coul=
d make it easier if the wallet could detect updates and prove they were val=
id.</div>
<div><br></div><div>This could be as simple as hard-coding a public key int=
o the client and checking a signature on the new binaries. But it could als=
o be more interesting...</div><div><br></div><div>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 sp=
end from that address announces a new release, and includes the expected ha=
sh of the file.</div>
<div><br></div><div>You would probably need some way to handle the differen=
t 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.</div>
<div><br></div><div>This provides zero benefit if the wallet software is al=
ready compromised, but I think this would allow trusted automatic update no=
tification, and a trusted way to deliver the expected hashes. It also might=
resolve some of the consternation around when a release is truly "rel=
eased", 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 cou=
ld 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</div=
>
<div><br></div><div>Formalizing the release process around a set of privkey=
s (or split shares of keys) may raise its own set of questions.</div><div><=
br></div><div>For the download itself, I've heard the advocates of anno=
uncing availability on the blockchain leading to a BitTorrent magnet link, =
but I also understand objections to adding an entire BitTorrent stack into =
a wallet.</div>
<div><div class=3D"h5"><div><br></div><div>On Tue, 31 Dec 2013 06:23:55 -08=
00, Mike Hearn <<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik=
e@plan99.net</a>> wrote:<br></div><br><blockquote style=3D"margin:0 0 0.=
80ex;border-left:#0000ff 2px solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">The site was actually moved onto a dedicated ser=
ver temporarily and it<br>
melted down under the load. I wouldn't call that no progress.<br></bloc=
kquote><div><br></div><div>Oh, it did? When was that? I must have missed th=
is excitement :)</div><div>=C2=A0</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 cl=
ear 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></bl=
ockquote><div><br></div><div>Well, that depends. If you watch Applebaums ta=
lk he is pushing TLS pretty hard, and saying that based on the access to th=
e source docs some of their MITM attacks can't beat TLS. It appears tha=
t 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.</di=
v>
<div><br></div><div>However if we can't find a server that won't me=
lt under the load, then that'd be an issue. We could consider hosting d=
ownloads on AppEngine or something else that can handle both high load and =
TLS.</div>
</div></div></div>
</blockquote><br><br><br></div></div></div></blockquote></div><br></div>
--001a11c2e60a6782a804eeea129b--
|