From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vy6xI-00010z-Te for bitcoin-development@lists.sourceforge.net; Tue, 31 Dec 2013 21:34:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me designates 192.241.179.72 as permitted sender) client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from mail.bluematt.me ([192.241.179.72]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Vy6xH-0002aU-6X for bitcoin-development@lists.sourceforge.net; Tue, 31 Dec 2013 21:34:28 +0000 Received: from [30.34.89.241] (unknown [172.56.16.62]) by mail.bluematt.me (Postfix) with ESMTPSA id 80E13405E9; Tue, 31 Dec 2013 21:34:20 +0000 (UTC) User-Agent: K-9 Mail for Android 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> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F6KKZTMEVZLMCHS889IDZWVKHSH1FI" From: Matt Corallo Date: Tue, 31 Dec 2013 13:33:54 -0800 To: Jeremy Spilman , Gregory Maxwell , Mike Hearn Message-ID: <4264e886-48de-40ac-921a-a60502595060@email.android.com> X-Spam-Score: -0.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 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 X-Headers-End: 1Vy6xH-0002aU-6X 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: Tue, 31 Dec 2013 21:34:29 -0000 ------F6KKZTMEVZLMCHS889IDZWVKHSH1FI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We already have a wonderful system for secure updating - gitian-downloade= r. We just neither use it not bother making actual gitian releases so any= one can use it to verify signatures of downloads. Jeremy Spilman wrote: >I didn't know about the dedicated server meltdown, it wasn't any of my=20 > >infra. Anyway, my previous offer still stands. > >One less 'security theater' approach would be if we could provide =20 >forward-validation of updates using the blockchain. It's always going >to =20 >be up to the user the first time they install the wallet to verify the=20 > >provenance of the binaries/source. From that point forward, we could >make =20 >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 >=20 >checking a signature on the new binaries. But it could also be more =20 >interesting... > >For example, a well known address on the blockchain corresponds to =20 >multi-sig with keys controlled by developers (or whatever key policy >the =20 >release team wants to impose). A spend from that address announces a >new =20 >release, and includes the expected hash of the file. > >You would probably need some way to handle the different release >targets. =20 >A more rigorous approach could identify all the various releases in >terms =20 >of a BIP32 xpubkey whose branches would correspond to the different =20 >release trains and platform builds. Spends from a node announce the =20 >release and the expected hash. > >This provides zero benefit if the wallet software is already >compromised, =20 >but I think this would allow trusted automatic update notification, and >a =20 >trusted way to deliver the expected hashes. It also might resolve some >of =20 >the consternation around when a release is truly "released", if that's=20 > >really a problem. > >I'm not sure how far along the slope you would want to go; 1) >announcing =20 >updates in the UI, 2) providing a button the user could click to verify >a =20 >binary matches its expected hash, 3) click to download and verify the =20 >upgrade matches the expected hash, 4) click to upgrade > >Formalizing the release process around a set of privkeys (or split >shares =20 >of keys) may raise its own set of questions. > >For the download itself, I've heard the advocates of announcing =20 >availability on the blockchain leading to a BitTorrent magnet link, but >I =20 >also understand objections to adding an entire BitTorrent stack into a=20 > >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 =20 >> pretty hard, and saying that based on the access to the source docs >some =20 >> of >their MITM attacks can't beat TLS. It appears that they have the=20 > >> capability to do bulk MITM and rewrite of downloads as Drak says but=20 > >> *not* when >TLS is present, that would force more targeted attacks. >So =20 >> 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 =20 >> that'd be an issue. We could consider hosting downloads on AppEngine >or =20 >> >something else that can handle both high load and TLS. > >------------------------------------------------------------------------ > >------------------------------------------------------------------------= ------ >Rapidly troubleshoot problems before they affect your business. Most IT > >organizations don't have a clear picture of how application performance > >affects their revenue. With AppDynamics, you get 100% visibility into >your=20 >Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >AppDynamics Pro! >http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg= .clktrk > >------------------------------------------------------------------------ > >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development ------F6KKZTMEVZLMCHS889IDZWVKHSH1FI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable We already have a wonderful system = for secure updating - gitian-downloader. We just neither use it not bothe= r making actual gitian releases so anyone can use it to verify signatures= of downloads.

Jeremy Spilman <jerem= y@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.

<= div>One less 'security theater' approach would be if we could provide for= ward-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 prove= nance of the binaries/source. From that point forward, we could make it e= asier 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 cou= ld also be more interesting...

For example, a = well known address on the blockchain corresponds to multi-sig with keys c= ontrolled 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 rel= ease targets. A more rigorous approach could identify all the various rel= eases 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 provi= des zero benefit if the wallet software is already compromised, but I thi= nk this would allow trusted automatic update notification, and a trusted = way to deliver the expected hashes. It also might resolve some of the con= sternation 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 but= ton 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) c= lick 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 announc= ing availability on the blockchain leading to a BitTorrent magnet link, b= ut 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 d= edicated 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 misse= d 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 Apple= baums talk he is pushing TLS pretty hard, and saying that based on the ac= cess 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 downloa= ds as Drak says but *not* when TLS is present, that would force more targ= eted attacks. So to me that implies that TLS does raise the bar and is wo= rth doing.

However if we can't find a server that won't melt u= nder 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.= 



<=
br />Rapidly troubleshoot problems before they affect your business. Most=
 IT 
organizations don't have a clear picture of how application per=
formance 
affects their revenue. With AppDynamics, you get 100% visi=
bility into your 
Java,.NET, & PHP application. Start your 15-da=
y FREE TRIAL of AppDynamics Pro!
http://pubad=
s.g.doubleclick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk


Bitcoin-developmen=
t mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------F6KKZTMEVZLMCHS889IDZWVKHSH1FI--