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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vamks-0001Dv-Qe for bitcoin-development@lists.sourceforge.net; Mon, 28 Oct 2013 13:21:14 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f47.google.com; Received: from mail-oa0-f47.google.com ([209.85.219.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vamkq-0000gE-TH for bitcoin-development@lists.sourceforge.net; Mon, 28 Oct 2013 13:21:14 +0000 Received: by mail-oa0-f47.google.com with SMTP id i1so3540486oag.34 for ; Mon, 28 Oct 2013 06:21:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.42.132 with SMTP id o4mr45581oel.93.1382966467432; Mon, 28 Oct 2013 06:21:07 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Mon, 28 Oct 2013 06:21:07 -0700 (PDT) In-Reply-To: <20131028121433.GA10254@netbook.cypherspace.org> References: <201310260341.41613.luke@dashjr.org> <20131028121433.GA10254@netbook.cypherspace.org> Date: Mon, 28 Oct 2013 14:21:07 +0100 X-Google-Sender-Auth: adEzut6jMcmAwbaB0-aChGKznws Message-ID: From: Mike Hearn To: Adam Back Content-Type: multipart/alternative; boundary=001a11c20a66071bd304e9ccf9c3 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 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bitcointalk.org] 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: 1Vamkq-0000gE-TH Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Payment protocol for onion URLs. 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: Mon, 28 Oct 2013 13:21:15 -0000 --001a11c20a66071bd304e9ccf9c3 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 28, 2013 at 1:14 PM, Adam Back wrote: > Maybe I voice this opinion a bit late in the cycle, but .... A bit late is one way to put it. All these topics and more were discussed to death a year ago when the payment protocol was first being designed. Bluntly, I think we're all sick of it. You are welcome to PGP sign your payment requests if you want to. If not, then please see my FAQ for discussion: https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143 tl;dr - the right way to tackle governments getting bogus certs issued is certificate transparency. All other suggestions tend to boil down to "here's some handwaving that doesn't actually solve the problem". By the way, the evidence from the Snowden case rather reinforces the strength of the CA system. Did we see stories about bulk usage of fake certificates? No. What we read is that the increased usage of SSL was a major game-changer for intelligence agencies. They "solve" SSL by compiling databases of private keys they obtain in various ways. True to form when the FBI wanted access to LavaBit, they tried to obtain his private keys rather than just push a convenient "give me a fake cert" button, and when it became known that Lavabit had to hand over their key, GoDaddy revoked their certificate. Industry policies forced their hand and those policies don't have a get-out clause for the FBI. It's without a doubt that there are government-issued fake certs floating about, somewhere, just due to the scale of hacking that's been taking place. However, demanding perfection in a system that handles security for over a billion people and tens of millions of operators is unreasonable. All we can ask for is that it it's being improved, which through initiatives like cert transparency, it is. Please, let's call time on these discussions. They long ago ceased to have any value. --001a11c20a66071bd304e9ccf9c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 28, 2013 at 1:14 PM, Adam Back <adam@cyphe= rspace.org> wrote:
Maybe I voice this opinion a bit late in the cycle, but ..= ..

A bit late is one way to put it. All these topics and m= ore were discussed to death a year ago when the payment protocol was first = being designed. Bluntly, I think we're all sick of it. You are welcome = to PGP sign your payment requests if you want to. If not, then please see m= y FAQ for discussion:


tl;dr= - the right way to tackle governments getting bogus certs issued is certif= icate transparency. All other suggestions tend to boil down to "here&#= 39;s some handwaving that doesn't actually solve the problem".

By the way, the evidence from the Snowden case rather r= einforces the strength of the CA system. Did we see stories about bulk usag= e of fake certificates? No. What we read is that the increased usage of SSL= was a major game-changer for intelligence agencies. They "solve"= SSL by compiling databases of private keys they obtain in various ways. Tr= ue to form when the FBI wanted access to LavaBit, they tried to obtain his = private keys rather than just push a convenient "give me a fake cert&q= uot; button, and when it became known that Lavabit had to hand over their k= ey, GoDaddy revoked their certificate. Industry policies forced their hand = and those policies don't have a get-out clause for the FBI.

It's without a doubt that there are government-issu= ed fake certs floating about, somewhere, just due to the scale of hacking t= hat's been taking place. However, demanding perfection in a system that= handles security for over a billion people and tens of millions of operato= rs is unreasonable. All we can ask for is that it it's being improved, = which through initiatives like cert transparency, it is.

Please, let's call time on these discussions. They = long ago ceased to have any value.
--001a11c20a66071bd304e9ccf9c3--