From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XJszC-0007Eo-GV for bitcoin-development@lists.sourceforge.net; Tue, 19 Aug 2014 23:38:42 +0000 X-ACL-Warn: Received: from s3.neomailbox.net ([178.209.62.157]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XJszA-0006b4-IN for bitcoin-development@lists.sourceforge.net; Tue, 19 Aug 2014 23:38:42 +0000 Message-ID: <53F3DFF7.9070709@jrn.me.uk> Date: Wed, 20 Aug 2014 00:38:31 +0100 From: J Ross Nicoll User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Johnathan Corgan , Gregory Maxwell , Justus Ranvier References: <0C0EF7F9-DBBA-4872-897D-63CFA3853726@ricmoo.com> <33D4B2E3-DBF0-444E-B76A-765C4C17E964@ricmoo.com> <53F37635.5070807@riseup.net> <53F38AC9.4000608@corganlabs.com> In-Reply-To: <53F38AC9.4000608@corganlabs.com> Content-Type: multipart/alternative; boundary="------------070000060604050307090605" X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1XJszA-0006b4-IN Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages 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: Tue, 19 Aug 2014 23:38:42 -0000 This is a multi-part message in MIME format. --------------070000060604050307090605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The concern is that if you can monitor traffic in and out of a single node, you can determine which transactions originate from it vs those which it relays. That's not great, certainly, but how many nodes actually require that level of security, and surely they can use Tor or VPN services if so? Further, unless the remote nodes are in some way trusted, you're changing the attack from read-only to requiring the ability to perform a man in the middle attack - that doesn't seem much harder to me. As Gregory states, there's been at least two recent serious if not catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin network had been vulnerable are the stuff of nightmares. Very difficult to see the risk/reward payoff being worthwhile. Ross On 19/08/2014 18:35, Johnathan Corgan wrote: > On 08/19/2014 09:38 AM, Gregory Maxwell wrote: > >> We've dodged several emergency scale vulnerabilities by not having TLS. > I'm still trying to understand the original premise that we want > encrypted communications between nodes. > > I can certainly see the value of having *authenticated* traffic with > specific nodes, using an HMAC for the protocol messages in place of the > current checksum. > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------070000060604050307090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The concern is that if you can monitor traffic in and out of a single node, you can determine which transactions originate from it vs those which it relays. That's not great, certainly, but how many nodes actually require that level of security, and surely they can use Tor or VPN services if so?

Further, unless the remote nodes are in some way trusted, you're changing the attack from read-only to requiring the ability to perform  a man in the middle attack - that doesn't seem much harder to me.

As Gregory states, there's been at least two recent serious if not catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin network had been vulnerable are the stuff of nightmares.

Very difficult to see the risk/reward payoff being worthwhile.

Ross


On 19/08/2014 18:35, Johnathan Corgan wrote:
On 08/19/2014 09:38 AM, Gregory Maxwell wrote:


We've dodged several emergency scale vulnerabilities by not having TLS.

I'm still trying to understand the original premise that we want
encrypted communications between nodes.

I can certainly see the value of having *authenticated* traffic with
specific nodes, using an HMAC for the protocol messages in place of the
current checksum.




------------------------------------------------------------------------------



_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------070000060604050307090605--