1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAAS2fgRRobkE2GdYomtJof7HCH-9ZczE9EBj7DBS-pCGscUSNQ@mail.gmail.com>
<201310260341.41613.luke@dashjr.org>
<CAAS2fgTWjPCdAZB22GdRWkfULS-L9XaqYRZqB=dcbGV1+My3nA@mail.gmail.com>
<20131028121433.GA10254@netbook.cypherspace.org>
Date: Mon, 28 Oct 2013 14:21:07 +0100
X-Google-Sender-Auth: adEzut6jMcmAwbaB0-aChGKznws
Message-ID: <CANEZrP2rzatT_M+bY9=VT=dOM+PMFPEqaRtQk0JsPcsw3khTmA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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.
--001a11c20a66071bd304e9ccf9c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Oct 28, 2013 at 1:14 PM, Adam Back <span dir=3D"lt=
r"><<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphe=
rspace.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Maybe I voice this opinion a bit late in the cycle, but ..=
..</blockquote>
<div><br></div><div>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:</div>
<div><br></div><div>=C2=A0 =C2=A0<a href=3D"https://bitcointalk.org/index.p=
hp?topic=3D300809.msg3225143#msg3225143">https://bitcointalk.org/index.php?=
topic=3D300809.msg3225143#msg3225143</a><br></div><div><br></div><div>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".</di=
v>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Please, let's call time on these discussions. They =
long ago ceased to have any value.</div></div></div></div>
--001a11c20a66071bd304e9ccf9c3--
|
