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 ) 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 ; 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: References: <52A3C8A5.7010606@gmail.com> <1795f3067ba3fcdd0caf978cc59ff024.squirrel@fruiteater.riseup.net> <52A435EA.7090405@gmail.com> <201312081237.24473.luke@dashjr.org> <20131212205106.GA4572@netbook.cypherspace.org> Date: Wed, 1 Jan 2014 15:10:05 +0000 X-Google-Sender-Auth: JsIT5RuE5cLuJY2NbiUqmu1pEeQ Message-ID: From: Mike Hearn To: Jeremy Spilman 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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.

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).



On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman &= lt;jeremy@taplink.co= > wrote:
I didn't know about the dedicated server meltdown, it wasn= 9;t any of my infra. Anyway, my previous offer still stands.

=
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.

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...

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.

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.

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.

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

Formalizing the release process around a set of privkey= s (or split shares of keys) may raise its own set of questions.
<= br>
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.

On Tue, 31 Dec 2013 06:23:55 -08= 00, Mike Hearn <mik= e@plan99.net> wrote:

The site was actually moved onto a dedicated ser= ver 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 th= is excitement :)
=C2=A0
Any idea how much load it had?<= br>

Perhaps I wasn't cl= ear 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 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.

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.




--001a11c2e60a6782a804eeea129b--