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; 
Content-Type: multipart/alternative;
	boundary=Apple-Mail-038E74F9-897D-4D6F-A5B8-F02F6010E1CF
Mime-Version: 1.0 (1.0)
From: Paul Puey <paul@airbitz.co>
In-Reply-To: <54D41353.5050205@voskuil.org>
Date: Thu, 5 Feb 2015 18:09:48 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <D0D537F5-201E-43D4-8BE7-ED34902EEF55@airbitz.co>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
	<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
	<54D3D636.1030308@voskuil.org>
	<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>
	<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>
	<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>
	<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>
	<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>
	<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
	<54D3FB4A.9010105@voskuil.org>
	<CALkkCJammCvVd6_1SYRvnxsMVj_x1AvS1VsSa6_76d0NWMDs=Q@mail.gmail.com>
	<54D400F0.9090406@voskuil.org>
	<CEB250A3-9014-4AF3-AEB7-E78BE19BF2F5@airbitz.co>
	<54D41353.5050205@voskuil.org>
To: Eric Voskuil <eric@voskuil.org>
Cc: William Swanson <william@airbitz.co>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
	transfer of Payment URI
Precedence: list


--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 <eric@voskuil.org> 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 <eric@voskuil.org
> <mailto:eric@voskuil.org>> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>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.<br><br><br><span style=3D=
"background-color: rgba(255, 255, 255, 0);"><br></span><table border=3D"0" s=
tyle=3D"-webkit-text-size-adjust: auto; font-size: medium; font-family: Helv=
etica, Arial, sans-serif;"><tbody><tr valign=3D"top"><td style=3D"width: aut=
o; vertical-align: top;"><font face=3D".HelveticaNeueInterface-M3"><span sty=
le=3D"font-size: 17px; -webkit-text-size-adjust: none; background-color: rgb=
a(255, 255, 255, 0);"><img src=3D"https://s3.amazonaws.com/webapp.wisestamp.=
com/v7Zg7GfIQ9mF5xlHZrZA_airbitzlogo.png" alt=3D"logo" style=3D"border: none=
; border-top-left-radius: 4px; border-top-right-radius: 4px; border-bottom-r=
ight-radius: 4px; border-bottom-left-radius: 4px;">&nbsp;&nbsp;&nbsp;<br></s=
pan></font></td><td><font face=3D".HelveticaNeueInterface-M3"><span style=3D=
"font-size: 17px; -webkit-text-size-adjust: none; background-color: rgba(255=
, 255, 255, 0);"><b>Paul Puey</b>&nbsp;CEO / Co-Founder, Airbitz Inc<br></sp=
an></font><div style=3D"margin-top: 0px; margin-bottom: 0px;"><font face=3D"=
.HelveticaNeueInterface-M3"><span style=3D"font-size: 17px; -webkit-text-siz=
e-adjust: none; background-color: rgba(255, 255, 255, 0);"><a style=3D"outli=
ne: none;"></a><a href=3D"tel:619.850.8624" x-apple-data-detectors=3D"true" x=
-apple-data-detectors-type=3D"telephone" x-apple-data-detectors-result=3D"0"=
>6</a><a href=3D"tel:619.850.8624" x-apple-data-detectors=3D"true" x-apple-d=
ata-detectors-type=3D"telephone" x-apple-data-detectors-result=3D"0">19.850.=
8624</a>&nbsp;|&nbsp;<a href=3D"http://airbitz.co/" target=3D"_blank" style=3D=
"outline: none;">http://airbitz.co</a>&nbsp;|&nbsp;San Diego</span></font></=
div><div style=3D"margin-top: 5px;"><font color=3D"#000000" face=3D".Helveti=
caNeueInterface-M3"><span style=3D"font-size: 17px; -webkit-text-size-adjust=
: none; background-color: rgba(255, 255, 255, 0);"><a href=3D"http://faceboo=
k.com/airbitz" target=3D"_blank" style=3D"outline: none;"><img src=3D"http:/=
/images.wisestamp.com/facebook.png" width=3D"16" style=3D"border: none;"></a=
>&nbsp;<a href=3D"http://twitter.com/airbitz" target=3D"_blank" style=3D"out=
line: none;"><img src=3D"http://images.wisestamp.com/twitter.png" width=3D"1=
6" alt=3D"" style=3D"border: none;"></a>&nbsp;<a href=3D"https://plus.google=
.com/118173667510609425617" target=3D"_blank" style=3D"outline: none;"><img s=
rc=3D"http://images.wisestamp.com/googleplus.png" width=3D"16" style=3D"bord=
er: none;"></a>&nbsp;<a href=3D"https://go.airbitz.co/comments/feed/" target=
=3D"_blank" style=3D"outline: none;"><img src=3D"http://images.wisestamp.com=
/blogRSS.png" width=3D"16" style=3D"border: none;"></a>&nbsp;<a href=3D"http=
://linkedin.com/in/paulpuey" target=3D"_blank" style=3D"outline: none;"><img=
 src=3D"http://images.wisestamp.com/linkedin.png" width=3D"16" alt=3D"" styl=
e=3D"border: none;"></a>&nbsp;<a href=3D"https://angel.co/paul-puey" target=3D=
"_blank" style=3D"outline: none;"><img src=3D"http://images.wisestamp.com/an=
gelList.png" width=3D"16" alt=3D"" style=3D"border: none;"></a></span></font=
></div></td></tr></tbody></table><table border=3D"0" style=3D"-webkit-text-s=
ize-adjust: auto; font-size: medium; font-family: Helvetica, Arial, sans-ser=
if;"><tbody><tr valign=3D"top"><td style=3D"width: auto; vertical-align: top=
;"><br></td><td><br></td></tr></tbody></table></div><div><br>On Feb 5, 2015,=
 at 5:05 PM, Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@vosku=
il.org</a>&gt; wrote:<br><br></div><div><span>On 02/05/2015 04:49 PM, Paul P=
uey wrote:</span><br><blockquote type=3D"cite"><span>The trust can be consid=
ered bootstrapped by visual verification of the</span><br></blockquote><bloc=
kquote type=3D"cite"><span>address prefix.</span><br></blockquote><span></sp=
an><br><span>Another (unspendable) address can trivially match the prefix. I=
magine</span><br><span>someone walking around in a mall with a phone in the p=
ocket with a</span><br><span>malicious app, just disrupting business by caus=
ing money to be burned.</span><br><span>Manual verification doesn't fix this=
 attack.</span><br><span></span><br><blockquote type=3D"cite"><span>If we ar=
e really concerned about someone jamming a Bluetooth signal</span><br></bloc=
kquote><blockquote type=3D"cite"><span>in a coffeeshop then the UI can encou=
rage verification of the prefix.</span><br></blockquote><span></span><br><sp=
an>I don't think it would be great to constrain a standard implementation</s=
pan><br><span>to low cost purchases or the need for manual verification, but=
 again</span><br><span>manual prefix verification isn't actually a solution.=
</span><br><span></span><br><blockquote type=3D"cite"><span>Much like how re=
gular Bluetooth requires 'pairing' via entering a 4-6</span><br></blockquote=
><blockquote type=3D"cite"><span>digit code.</span><br></blockquote><span></=
span><br><span>An appeal to the security of BT bootstrapping isn't exactly f=
lattering.</span><br><span></span><br><span>You know I love Airbitz, and I k=
now you guys are extremely privacy</span><br><span>conscious. I personally w=
ould have no problem using this feature under</span><br><span>certain circum=
stances. My question is only whether it would be wise to</span><br><span>sta=
ndardize on the proposal as-is.</span><br><span></span><br><span>e</span><br=
><span></span><br><blockquote type=3D"cite"><span>On Feb 5, 2015, at 3:46 PM=
, Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a><=
/span><br></blockquote><blockquote type=3D"cite"><span>&lt;<a href=3D"mailto=
:eric@voskuil.org">mailto:eric@voskuil.org</a>&gt;&gt; wrote:</span><br></bl=
ockquote><blockquote type=3D"cite"><span></span><br></blockquote><blockquote=
 type=3D"cite"><span>On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=
=8B=C5=A1tiak wrote:</span><br></blockquote><blockquote type=3D"cite"><block=
quote type=3D"cite"><blockquote type=3D"cite"><span>A BIP-70 signed payment r=
equest in the initial broadcast can resolve the</span><br></blockquote></blo=
ckquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><span>integrity issues, but because of the public nat=
ure of the broadcast</span><br></blockquote></blockquote></blockquote><block=
quote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><spa=
n>coupled with strong public identity, the privacy compromise is much</span>=
<br></blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><span>worse. Now transactions a=
re cryptographically tainted.</span><br></blockquote></blockquote></blockquo=
te><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"c=
ite"><span></span><br></blockquote></blockquote></blockquote><blockquote typ=
e=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>This is=
 also the problem with BIP-70 over the web. TLS and other</span><br></blockq=
uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span>security precautions aside, an interl=
oper on the communication, desktop,</span><br></blockquote></blockquote></bl=
ockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote typ=
e=3D"cite"><span>datacenter, etc., can capture payment requests and strongly=
 correlate</span><br></blockquote></blockquote></blockquote><blockquote type=
=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>transact=
ions to identities in an automated manner. The payment request</span><br></b=
lockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span>must be kept private between the=
 parties, and that's hard to do.</span><br></blockquote></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><span></span><br><=
/blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"=
><span>What about using encryption with forward secrecy? Merchant would</spa=
n><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D=
"cite"><span>generate signed request containing public ECDH part, buyer woul=
d send</span><br></blockquote></blockquote><blockquote type=3D"cite"><blockq=
uote type=3D"cite"><span>back transaction encrypted with ECDH and his public=
 ECDH part. If</span><br></blockquote></blockquote><blockquote type=3D"cite"=
><blockquote type=3D"cite"><span>receiving address/amount is meant to be pri=
vate, use commit protocol</span><br></blockquote></blockquote><blockquote ty=
pe=3D"cite"><blockquote type=3D"cite"><span>(see ZRTP/RedPhone) and short au=
thentication phrase (which is hard to</span><br></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><span>spoof thanks to comm=
it protocol - see RedPhone)?</span><br></blockquote></blockquote><blockquote=
 type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span=
>Hi Martin,</span><br></blockquote><blockquote type=3D"cite"><span></span><b=
r></blockquote><blockquote type=3D"cite"><span>The problem is that you need t=
o verify the ownership of the public key.</span><br></blockquote><blockquote=
 type=3D"cite"><span>A MITM can substitute the key. If you don't have verifi=
able identity</span><br></blockquote><blockquote type=3D"cite"><span>associa=
ted with the public key (PKI/WoT), you need a shared secret (such</span><br>=
</blockquote><blockquote type=3D"cite"><span>as a secret phrase). But the pr=
oblem is then establishing that secret</span><br></blockquote><blockquote ty=
pe=3D"cite"><span>over a public channel.</span><br></blockquote><blockquote t=
ype=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>Y=
ou can bootstrap a private session over the untrusted network using a</span>=
<br></blockquote><blockquote type=3D"cite"><span>trusted public key (PKI/WoT=
). But the presumption is that you are</span><br></blockquote><blockquote ty=
pe=3D"cite"><span>already doing this over the web (using TLS). That process i=
s subject to</span><br></blockquote><blockquote type=3D"cite"><span>attack a=
t the CA. WoT is not subject to a CA attack, because it's</span><br></blockq=
uote><blockquote type=3D"cite"><span>decentralized. But it's also not suffic=
iently deployed for some scenarios.</span><br></blockquote><blockquote type=3D=
"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>e</span=
><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><s=
pan></span><br></div></body></html>=

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