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 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 ; 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 In-Reply-To: <201112191145.02427.andyparkins@gmail.com> Date: Mon, 19 Dec 2011 14:46:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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