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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RbbTG-0005Bf-RJ
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 17:21:22 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RbbTE-0002F7-KJ
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 17:21:22 +0000
Received: by werm13 with SMTP id m13so820193wer.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 09:21:14 -0800 (PST)
Received: by 10.216.143.66 with SMTP id k44mr703174wej.56.1324056074514;
Fri, 16 Dec 2011 09:21:14 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id fi11sm15316190wbb.9.2011.12.16.09.21.12
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 16 Dec 2011 09:21:13 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Fri, 16 Dec 2011 17:21:11 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<20111216083536.GA20470@ulyssis.org>
<CAJ1JLtsRGF8wQBE0Uym67baw4wWT6hGamGjSPWyuB_em479y9Q@mail.gmail.com>
In-Reply-To: <CAJ1JLtsRGF8wQBE0Uym67baw4wWT6hGamGjSPWyuB_em479y9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2475524.HNXItCd5CJ";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201112161721.11498.andyparkins@gmail.com>
X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(andyparkins[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RbbTE-0002F7-KJ
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: Fri, 16 Dec 2011 17:21:22 -0000
--nextPart2475524.HNXItCd5CJ
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On 2011 December 16 Friday, Rick Wesson wrote:
> I believe that any URI scheme will still leverage DNS and inherit any
> base issues you would have with TXT records. I suggest looking at DANE
HTTPS takes care of that.
> and reviewing their work on hardening certificate (x.509)
> infrastructure as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.
This is the only real problem with HTTPS: we would be centralising part of =
our=20
otherwise decentralised system. CAs are certainly a risk.
However, trust is needed somewhere in the communication. There is no way t=
o=20
securely communicate between A and B without the use of some previously=20
trusted secure channel -- in Joe Sixpack's case it's by assuming that the=20
browser he downloaded came with an untainted CA list, and that the CAs are=
=20
trustworthy. Neither of which is guaranteed. Until and unless we get PGP=
=20
support in browsers, CAs are all that we have.
Worrying about CAs misses the point anyway; if we're being that paranoid --=
=20
how did A tell B the appropriate alias to use for a lookup? Was that chann=
el=20
secure too? I could set up a MITM server that simply looks for the alias=20
"RICKWESSON@bitcoinaliases.org" and rewrites it to=20
"ANDYPARKINS@bitcoinaliases.org". When the answer to that problem is HTTPS=
=20
(or some other system that requires a previously authorised secure channel =
for=20
transfer of trust), then we're back where we started, and HTTPS is acceptab=
le.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart2475524.HNXItCd5CJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk7rfgcACgkQwQJ9gE9xL21YQgCeNbJlPgB49yyQgRqMplkR3rQU
CiUAoNi5M+IzndUkE38wkIsc2gytwOPY
=eWzb
-----END PGP SIGNATURE-----
--nextPart2475524.HNXItCd5CJ--
|
