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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UX6gS-0001xX-AV
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Apr 2013 09:17:12 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UX6gR-00038H-Cq
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Apr 2013 09:17:12 +0000
Received: by mail-ob0-f179.google.com with SMTP id oi10so245694obb.38
for <bitcoin-development@lists.sourceforge.net>;
Tue, 30 Apr 2013 02:17:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.40.129 with SMTP id x1mr1961844obk.15.1367313426048;
Tue, 30 Apr 2013 02:17:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Tue, 30 Apr 2013 02:17:05 -0700 (PDT)
In-Reply-To: <CA+CODZEiWTrmFzrMi2Mi0qtH3dWO5UWx_j09iUwV2qm1O=3o0A@mail.gmail.com>
References: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
<20130428180304.GA30115@crunch>
<CA+CODZEiWTrmFzrMi2Mi0qtH3dWO5UWx_j09iUwV2qm1O=3o0A@mail.gmail.com>
Date: Tue, 30 Apr 2013 11:17:05 +0200
X-Google-Sender-Auth: Q_juHMc56UfZZNd47o2unzYBaOo
Message-ID: <CANEZrP2JDc244xvR0ayM700Vy_h3G=aAUUgfxtOcxd0ZeB9b8g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy.spilman@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c30ac20e710104db90770b
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1UX6gR-00038H-Cq
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
"timo.hanke@web.de" <timo.hanke@web.de>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
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: Tue, 30 Apr 2013 09:17:12 -0000
--001a11c30ac20e710104db90770b
Content-Type: text/plain; charset=UTF-8
> Backing up a step, I'm not sure what the threat model is for signing the
> refund address? The same process that's signing the transaction is doing an
> HTTPS POST with the refund address.
>
It's a real threat, albeit an exotic one. The threat model is a malware
compromised host, with a wallet (possibly a low power hardware wallet like
a Trezor) that can understand the payment protocol and sign transactions,
but maybe not do a whole lot more than that. For instance, probably it
cannot do HTTPS connections itself. So a virus on the host could swap the
refund address for one that is owned by the attacker, and then try to make
the merchant issue an automatic refund, thus bouncing the funds back off
the merchant to the them.
If there are merchants that offer large, automatic refunds, it could be an
issue. I'm not sure how common that might be in reality. Steven or Tony
would know. Timo's protocol is an interesting solution, but again, at this
point the feature set for v1 is pretty much locked down.
--001a11c30ac20e710104db90770b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<div> </div>
<div>Backing up a step, I'm not sure what the threat model is for signi=
ng the=20
refund address? The same process that's signing the transaction is doin=
g an=20
HTTPS POST with the refund address.</div></div></blockquote><div><br></div>=
<div style>It's a real threat, albeit an exotic one. The threat model i=
s a malware compromised host, with a wallet (possibly a low power hardware =
wallet like a Trezor) that can understand the payment protocol and sign tra=
nsactions, but maybe not do a whole lot more than that. For instance, proba=
bly it cannot do HTTPS connections itself. So a virus on the host could swa=
p the refund address for one that is owned by the attacker, and then try to=
make the merchant issue an automatic refund, thus bouncing the funds back =
off the merchant to the them.</div>
<div style><br></div><div style>If there are merchants that offer large, au=
tomatic refunds, it could be an issue. I'm not sure how common that mig=
ht be in reality. Steven or Tony would know. Timo's protocol is an inte=
resting solution, but again, at this point the feature set for v1 is pretty=
much locked down.</div>
</div></div></div>
--001a11c30ac20e710104db90770b--
|
