public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol for onion URLs.
Date: Mon, 28 Oct 2013 14:21:07 +0100	[thread overview]
Message-ID: <CANEZrP2rzatT_M+bY9=VT=dOM+PMFPEqaRtQk0JsPcsw3khTmA@mail.gmail.com> (raw)
In-Reply-To: <20131028121433.GA10254@netbook.cypherspace.org>

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Mon, Oct 28, 2013 at 1:14 PM, Adam Back <adam@cypherspace•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 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.

[-- Attachment #2: Type: text/html, Size: 2557 bytes --]

  reply	other threads:[~2013-10-28 13:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-26  3:31 Gregory Maxwell
2013-10-26  3:41 ` Luke-Jr
2013-10-26  4:06   ` Gregory Maxwell
2013-10-28 12:14     ` Adam Back
2013-10-28 13:21       ` Mike Hearn [this message]
2013-10-26  3:55 ` Gavin Andresen
2013-10-26  4:15 ` Peter Todd
2013-10-28  5:58 ` John Dillon
2013-10-28 19:37   ` Jeremy Spilman
2013-10-31  0:44     ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANEZrP2rzatT_M+bY9=VT=dOM+PMFPEqaRtQk0JsPcsw3khTmA@mail.gmail.com' \
    --to=mike@plan99$(echo .)net \
    --cc=adam@cypherspace$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox