Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YJYMr-0002IU-Ah for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 02:10:01 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of airbitz.co designates 209.85.220.46 as permitted sender) client-ip=209.85.220.46; envelope-from=paul@airbitz.co; helo=mail-pa0-f46.google.com; Received: from mail-pa0-f46.google.com ([209.85.220.46]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YJYMo-0006OU-SZ for bitcoin-development@lists.sourceforge.net; Fri, 06 Feb 2015 02:10:01 +0000 Received: by mail-pa0-f46.google.com with SMTP id lj1so13897121pab.5 for ; Thu, 05 Feb 2015 18:09:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dyDKhDhLeKrfX1Jl+KfJgNmbzjfE+OuDoDWJtm535r8=; b=gPDfHRbr4599PsVrCfpL07reem/JI1JjnPFcDByn02QN0qx40ZZIV+E7iDr+D2Fw/A vP6K+qlrNDBK8ZaXvYWiCU9OJ6z6boPiU/DZILgoll2uKmuqOfuy/V/UsvGtuVsngsy5 0bsup87z6vyzXgJVPuVk6BtX1G1xGtg5SJ+08iHQNjpW+0JSazKI01gyZpRy2HhDV1eE hZpos6FMRt/XsxBIMwEqZlwxEatkHnhGvj711HjceI9iF2S3Qnj8tuxzTuoFHX/VI6Qt P6CCrinVO3G2N7d4Yzy1VRfW4hheoUaTqAuq4N36kAhxPNzP+fb4046t+9gfsZuf5gYa wG8g== X-Gm-Message-State: ALoCoQnBXFXSWIbkr1/N1gyG/kUx9swFcypcOIh86kGVnSU7DCY9Wy50rvv2jKW/309AxcasrRAK X-Received: by 10.66.186.110 with SMTP id fj14mr1843551pac.98.1423188593032; Thu, 05 Feb 2015 18:09:53 -0800 (PST) Received: from [10.204.163.123] (mobile-166-171-251-007.mycingular.net. [166.171.251.7]) by mx.google.com with ESMTPSA id b6sm6278973pdk.94.2015.02.05.18.09.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 18:09:51 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-038E74F9-897D-4D6F-A5B8-F02F6010E1CF Mime-Version: 1.0 (1.0) From: Paul Puey X-Mailer: iPhone Mail (12B411) In-Reply-To: <54D41353.5050205@voskuil.org> Date: Thu, 5 Feb 2015 18:09:48 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <54D3D636.1030308@voskuil.org> <279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com> <6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org> <54D3FB4A.9010105@voskuil.org> <54D400F0.9090406@voskuil.org> <54D41353.5050205@voskuil.org> To: Eric Voskuil X-Spam-Score: -0.3 (/) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.3 HTML_FONT_FACE_BAD BODY: HTML font face is not a word 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars -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 T_REMOTE_IMAGE Message contains an external image X-Headers-End: 1YJYMo-0006OU-SZ Cc: William Swanson , Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI 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: Fri, 06 Feb 2015 02:10:01 -0000 --Apple-Mail-038E74F9-897D-4D6F-A5B8-F02F6010E1CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for all the feedback Eric. You know we value all that you have to say= . That's what this forum is for. We're looking for great ideas to harden thi= s protocol and we're not closed to better ideas and we'll improve it as sugg= estions come up. =20 Paul Puey CEO / Co-Founder, Airbitz Inc 619.850.8624 | http://airbitz.co | San Diego =20 On Feb 5, 2015, at 5:05 PM, Eric Voskuil wrote: > On 02/05/2015 04:49 PM, Paul Puey wrote: > The trust can be considered bootstrapped by visual verification of the > address prefix. Another (unspendable) address can trivially match the prefix. Imagine someone walking around in a mall with a phone in the pocket with a malicious app, just disrupting business by causing money to be burned. Manual verification doesn't fix this attack. > If we are really concerned about someone jamming a Bluetooth signal > in a coffeeshop then the UI can encourage verification of the prefix. I don't think it would be great to constrain a standard implementation to low cost purchases or the need for manual verification, but again manual prefix verification isn't actually a solution. > Much like how regular Bluetooth requires 'pairing' via entering a 4-6 > digit code. An appeal to the security of BT bootstrapping isn't exactly flattering. You know I love Airbitz, and I know you guys are extremely privacy conscious. I personally would have no problem using this feature under certain circumstances. My question is only whether it would be wise to standardize on the proposal as-is. e > On Feb 5, 2015, at 3:46 PM, Eric Voskuil > wrote: >=20 > On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak wro= te: >>> A BIP-70 signed payment request in the initial broadcast can resolve the= >>> integrity issues, but because of the public nature of the broadcast >>> coupled with strong public identity, the privacy compromise is much >>> worse. Now transactions are cryptographically tainted. >>>=20 >>> This is also the problem with BIP-70 over the web. TLS and other >>> security precautions aside, an interloper on the communication, desktop,= >>> datacenter, etc., can capture payment requests and strongly correlate >>> transactions to identities in an automated manner. The payment request >>> must be kept private between the parties, and that's hard to do. >>=20 >> What about using encryption with forward secrecy? Merchant would >> generate signed request containing public ECDH part, buyer would send >> back transaction encrypted with ECDH and his public ECDH part. If >> receiving address/amount is meant to be private, use commit protocol >> (see ZRTP/RedPhone) and short authentication phrase (which is hard to >> spoof thanks to commit protocol - see RedPhone)? >=20 > Hi Martin, >=20 > The problem is that you need to verify the ownership of the public key. > A MITM can substitute the key. If you don't have verifiable identity > associated with the public key (PKI/WoT), you need a shared secret (such > as a secret phrase). But the problem is then establishing that secret > over a public channel. >=20 > You can bootstrap a private session over the untrusted network using a > trusted public key (PKI/WoT). But the presumption is that you are > already doing this over the web (using TLS). That process is subject to > attack at the CA. WoT is not subject to a CA attack, because it's > decentralized. But it's also not sufficiently deployed for some scenarios.= >=20 > e --Apple-Mail-038E74F9-897D-4D6F-A5B8-F02F6010E1CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for all the feedback Eric. You k= now we value all that you have to say. That's what this forum is for. We're l= ooking for great ideas to harden this protocol and we're not closed to bette= r ideas and we'll improve it as suggestions come up.



3D"logo"   
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.= 8624 | http://airbitz.co | San Diego
 3D""    3D""



On Feb 5, 2015,= at 5:05 PM, Eric Voskuil <eric@vosku= il.org> wrote:

On 02/05/2015 04:49 PM, Paul P= uey wrote:
The trust can be consid= ered bootstrapped by visual verification of the
address prefix.

Another (unspendable) address can trivially match the prefix. I= magine
someone walking around in a mall with a phone in the p= ocket with a
malicious app, just disrupting business by caus= ing money to be burned.
Manual verification doesn't fix this= attack.

If we ar= e really concerned about someone jamming a Bluetooth signal
in a coffeeshop then the UI can encou= rage verification of the prefix.

I don't think it would be great to constrain a standard implementation
to low cost purchases or the need for manual verification, but= again
manual prefix verification isn't actually a solution.=

Much like how re= gular Bluetooth requires 'pairing' via entering a 4-6
digit code.

An appeal to the security of BT bootstrapping isn't exactly f= lattering.

You know I love Airbitz, and I k= now you guys are extremely privacy
conscious. I personally w= ould have no problem using this feature under
certain circum= stances. My question is only whether it would be wise to
sta= ndardize on the proposal as-is.

e
On Feb 5, 2015, at 3:46 PM= , Eric Voskuil <eric@voskuil.org<= /span>
<mailto:eric@voskuil.org>> wrote:

On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93= =8B=C5=A1tiak wrote:
A BIP-70 signed payment r= equest in the initial broadcast can resolve the
integrity issues, but because of the public nat= ure of the broadcast
coupled with strong public identity, the privacy compromise is much=
worse. Now transactions a= re cryptographically tainted.

This is= also the problem with BIP-70 over the web. TLS and other
security precautions aside, an interl= oper on the communication, desktop,
datacenter, etc., can capture payment requests and strongly= correlate
transact= ions to identities in an automated manner. The payment request
must be kept private between the= parties, and that's hard to do.

<= /blockquote>
What about using encryption with forward secrecy? Merchant would
generate signed request containing public ECDH part, buyer woul= d send
back transaction encrypted with ECDH and his public= ECDH part. If
receiving address/amount is meant to be pri= vate, use commit protocol
(see ZRTP/RedPhone) and short au= thentication phrase (which is hard to
spoof thanks to comm= it protocol - see RedPhone)?

Hi Martin,
The problem is that you need t= o verify the ownership of the public key.
A MITM can substitute the key. If you don't have verifi= able identity
associa= ted with the public key (PKI/WoT), you need a shared secret (such
=
as a secret phrase). But the pr= oblem is then establishing that secret
over a public channel.

Y= ou can bootstrap a private session over the untrusted network using a=
trusted public key (PKI/WoT= ). But the presumption is that you are
already doing this over the web (using TLS). That process i= s subject to
attack a= t the CA. WoT is not subject to a CA attack, because it's
decentralized. But it's also not suffic= iently deployed for some scenarios.

e


= --Apple-Mail-038E74F9-897D-4D6F-A5B8-F02F6010E1CF--