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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org,
	your thoughts?
Precedence: list

--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&#39;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>&gt;</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&#39;t know about the dedicated server meltdown, it wasn&#3=
9;t any of my infra. Anyway, my previous offer still stands.</div><div><br>=
</div><div>One less &#39;security theater&#39; approach would be if we coul=
d provide forward-validation of updates using the blockchain. It&#39;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 &quot;rel=
eased&quot;, if that&#39;s really a problem.</div>
<div><br></div><div>I&#39;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&#39;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 &lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik=
e@plan99.net</a>&gt; 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&#39;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&#39;t cl=
ear on the point I was making Drak&#39;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&#39;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&#39;t find a server that won&#39;t me=
lt under the load, then that&#39;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--