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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
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 <solar@heliacal.net>) id 1RcekO-00046M-Dr
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Dec 2011 15:03:24 +0000
X-ACL-Warn:
Received: from pelican.heliacal.net ([173.246.103.92] helo=pelican)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RcekM-0005IC-6u for bitcoin-development@lists.sourceforge.net;
Mon, 19 Dec 2011 15:03:24 +0000
Received: from laszlo.jax.imobile3.com (laszlo.jax.imobile3.com
[199.189.207.150])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by pelican (Postfix) with ESMTPSA id 6639B19122
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 Dec 2011 14:46:14 +0000 (UTC)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: solar <solar@heliacal.net>
In-Reply-To: <201112191145.02427.andyparkins@gmail.com>
Date: Mon, 19 Dec 2011 14:46:12 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5367391-7CC5-4BCB-9AC4-4E38707DAF81@heliacal.net>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<CAJna-HjyZv2y9grNdnKKG8k6tn7jdW=zL=vtrALpeW8jkuzV6Q@mail.gmail.com>
<CAGQP0AEEzOjc2ayOJYgs_oh4RG91Dp4JSHUjyPX=qdp+ri6oSg@mail.gmail.com>
<201112191145.02427.andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
X-Mailer: Apple Mail (2.1251.1)
X-Helo-Check: bad, Not FQDN (pelican)
X-Spam-Score: -2.1 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
0.5 VA_HELO_CHECK Host Used Invalid or Forged HELO/EHLO
-2.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
X-Headers-End: 1RcekM-0005IC-6u
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
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, 19 Dec 2011 15:03:24 -0000
I think HTTPS, and more specifically x.509 PKI certs and CAs are =
generally a good idea and (historical implementation bugs aside) the =
concept is technically sound and secure. What is a bad idea (in my =
opinion) is to trust a software vendor to decide who you should trust.. =
thus it is a bad idea for bitcoin software to promise any trust.
The part where the concept becomes flawed is trusting 3rd parties who =
have no relationship with you, to serve your interests. Now I'm just =
generalizing here and this is not universally true.. but internet CAs =
just want to sell certificates - they generally don't care beyond that, =
and they abuse the certificate validity dates to charge more money. All =
this is done under the guise of wanting to provide a secure experience =
to users without a prior relationship to the entity being identified. I =
propose that trying to follow this paradigm in bitcoin alias resolution =
is a bad idea because it tries to solve 2 problems at once, one of which =
does not have any 'good' solution, and forces a specific policy.
First, we need to resolve an alias to a bitcoin address somehow.. but =
secondly we need to establish trust with the entity doing the alias =
resolution - to make sure that we can trust the response.
When resolving an alias you will have to query an untrusted server, =
possibly being proxied by an 'attacker'. Presumably, an x.509 =
certificate will be presented, possibly self signed or chained off a =
self generated CA or whatever else.. but if it's your first contact then =
there is no possible way to know if it's correct or not. You would have =
to retrieve the correct public key of the CA to compare to first, =
possibly out of band. Get it from my website, compare it to my business =
card, send me an email and I'll send it to you, or get it from some =
other source using some other pre existing trust (a centralized and =
possibly private directory perhaps). The point is, the reason there is =
so much disagreement is because there is no good way to trust the =
resolver if you don't create that trust relationship prior to resolving =
an alias from it.
I think that having to pre-trust the resolver would be an acceptable =
solution to all.. Those whose policy requires a simpler process can get =
a 3rd party CA list, much like the ones provided with web browsers and =
operating systems. Those with strict verification policies can choose =
to pre verify every public key.. and these processes are familiar to =
many organizations using PKI for other things already. In a client, =
presenting the usual certificate detail dialog, showing the public key, =
subject, issuer, and thumbprint would be sufficient to allow users to =
implement their own policies without forcing it one way or another.
Please consider that while some organizations or users might require =
strong anonymity and pre existing trust, there are others who may want =
to do the opposite and that is just as valid, even if you or 'everyone =
else' disagrees with that. In the case of bitcoin, it will be used as =
part of a larger system, and whatever concerns are created by 'insecure' =
alias resolution may well be addressed in another part of the system. =
The most successful standards and implementations are the ones which =
provide the most flexibility - primarily because that allows users to =
extend them in ways the original designers didn't necessarily plan for.
Thanks,
Laszlo
On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:
> On 2011 December 19 Monday, Jorge Tim=F3n wrote:
>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>> know the HTTPS possible attack, but maybe it needs a warning message
>> too, from what you people are saying. Although using namecoin to
>=20
> The problems with HTTPS have been social rather than technical. =
Multiple CAs=20
> have been strong-armed by governments or tricked into issuing fake=20
> certificates by scammers. There is no technical measure around that. =
By=20
> using the CA certificate we are saying to the system "here is someone =
I trust=20
> to issue a certificate". So far, with a large number of CAs, that =
trust is=20
> misplaced.
>=20
> I'm of the opinion though that this problem is outside the remit of =
bitcoin to=20
> solve.
>=20
> Perhaps we should be more strict about which CA certificates are =
trusted by=20
> the bitcoin client: say restrict it to those who have demonstrably =
good=20
> practices for verifying identity; rather than the ridiculous amount of =
trust=20
> that comes pre-installed for me in my browser.
>=20
>=20
>=20
> Andy
>=20
> --=20
> Dr Andy Parkins
> andyparkins@gmail.com
> =
--------------------------------------------------------------------------=
----
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for=20=
> developers. It will provide a great way to learn Windows Azure and =
what it=20
> provides. You can attend the event by watching it streamed LIVE =
online. =20
> Learn more at =
http://p.sf.net/sfu/ms-windowsazure_______________________________________=
________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
