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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1V4UR2-0005LG-B1
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Jul 2013 11:19:16 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.169 as permitted sender)
client-ip=74.125.82.169; envelope-from=gavinandresen@gmail.com;
helo=mail-we0-f169.google.com;
Received: from mail-we0-f169.google.com ([74.125.82.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V4UQx-000078-Td
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Jul 2013 11:19:16 +0000
Received: by mail-we0-f169.google.com with SMTP id n5so485536wev.14
for <bitcoin-development@lists.sourceforge.net>;
Wed, 31 Jul 2013 04:19:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.102.37 with SMTP id fl5mr3889018wib.52.1375269545702;
Wed, 31 Jul 2013 04:19:05 -0700 (PDT)
Received: by 10.194.82.198 with HTTP; Wed, 31 Jul 2013 04:19:05 -0700 (PDT)
In-Reply-To: <CANEZrP3pp6N+B4HgRF_xpp-sm7gkkK-NoV6nKKnOzes_2ubT4g@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
<CANEZrP3pp6N+B4HgRF_xpp-sm7gkkK-NoV6nKKnOzes_2ubT4g@mail.gmail.com>
Date: Wed, 31 Jul 2013 21:19:05 +1000
Message-ID: <CABsx9T1WB+ZraSGXrLJw1F9a4k+KHZYBPJ2cL8ufUYkayfQStA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d044517f7bdfe7a04e2cce4b1
X-Spam-Score: -0.6 (/)
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1V4UQx-000078-Td
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
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: Wed, 31 Jul 2013 11:19:16 -0000
--f46d044517f7bdfe7a04e2cce4b1
Content-Type: text/plain; charset=ISO-8859-1
Thanks, Mike!
"PaymentRequest messages larger than 50,000 bytes should be rejected by
> the merchant's server, to mitigate denial-of-service attacks."
>
> Do you mean "users wallet" here?
>
Yes, fixed.
> You could note in the motivation section two more motivations:
> 1) That the protocol can be a foundation on which other features are built
>
I don't like putting "this is what we think will happen in the future"
types of statements in specifications, so I'm inclined to leave that out.
> 2) That it is required to assist hardware wallets when there is a virus on
> the system
>
Added:
"Resistance from man-in-the-middle attacks that replace a merchant's
bitcoin address with an attacker's address before a transaction is
authorized with a hardware wallet."
Perhaps note in the BIP that the merchant should not assume the
> merchant_data field is trustworthy - malicious buyers could rewrite it as
> they see fit. Point out that a good way to use this is to serialize server
> state, signed by a merchant-only key, in the same way one might use an HTTP
> cookie.
>
Added:
"Note that malicious clients may modify the merchant_data, so should be
authenticated in some way (for example, signed with a merchant-only key)."
> "PaymentDetails.payment_url must be secure against man-in-the-middle
> attacks that might alter Payment.refund_to (if using HTTP, it must be
> TLS-protected).
>
> This says "must", but what should a client do here if the payment URL is
> not HTTPS? I suggest weakening this to "should", as sometimes TLS is
> redundant (e.g. if you're sending to a Tor hidden service).
>
done.
> The PaymentACK message contains a copy of Payment, but the BIP doesn't say
> what to do with it. I assume this means a client is free to ignore it and
> rely on TCP state to figure out the payment/ack connection instead? It may
> be worth noting that explicitly.
>
Added:
"payment | Copy of the Payment message that triggered this PaymentACK.
Clients may ignore this if they implement another way of associating
Payments with PaymentACKs."
>
> In the certificates section, you could observe that "validation" means
> "verification that it correctly chains to a trusted root authority, where
> trusted roots may be obtained from the operating system. If there is no
> operating system, the Mozilla root store is recommended".
>
Modified that section to say:
"...followed by additional certificates, with each subsequent certificate
being the one used to certify the previous one, up to a trusted root
authority. The recipient must verify the certificate chain according to
[RFC5280] and reject the PaymentRequest if any validation failure occurs.
Trusted root certificates may be obtained from the operating system; if
validation is done on a device without an operating system, the Mozilla
root store<http://www.mozilla.org/projects/security/certs/included/index.html>
is
recommended."
--
--
Gavin Andresen
--f46d044517f7bdfe7a04e2cce4b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks, Mike!<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>=A0 =A0"<span style=3D"line-height:1.5em">Pa=
ymentRequest messages larger than 50,000 bytes should be rejected by the me=
rchant's server, to mitigate denial-of-service attacks."</span></d=
iv>
<div><span style=3D"line-height:1.5em"><br></span></div><div><span style=3D=
"line-height:1.5em">Do you mean "users wallet" here?</span></div>=
</div></blockquote><div><br></div><div>Yes, fixed.</div><div><br></div><div=
>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=
=3D"line-height:1.5em"></span></div><div><span style=3D"line-height:1.5em">=
You could note in the motivation section two more motivations:</span></div>
<div><span style=3D"line-height:1.5em">1) That the protocol can be a founda=
tion on which other features are built</span></div></div></blockquote><div>=
<br></div><div>I don't like putting "this is what we think will ha=
ppen in the future" types of statements in specifications, so I'm =
inclined to leave that out.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span st=
yle=3D"line-height:1.5em">2) That it is required to assist hardware wallets=
when there is a virus on the system</span></div>
</div></blockquote><div><br></div><div>Added:</div><div><br></div><div>&quo=
t;<span style=3D"background-color:rgb(255,255,255);font-family:sans-serif;f=
ont-size:13px;line-height:19.1875px">Resistance from man-in-the-middle atta=
cks that replace a merchant's bitcoin address with an attacker's ad=
dress before a transaction is authorized with a hardware wallet."</spa=
n></div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<div><span style=3D"line-height:1.5em">Perhaps note in the BIP that the mer=
chant should not assume the merchant_data field is trustworthy - malicious =
buyers could rewrite it as they see fit. Point out that a good way to use t=
his is to serialize server state, signed by a merchant-only key, in the sam=
e way one might use an HTTP cookie.</span></div>
</div></blockquote><div>=A0</div><div>Added:</div><div><br></div><div>"=
;<span style=3D"background-color:rgb(255,255,255);font-family:sans-serif;fo=
nt-size:13px;line-height:19.1875px">Note that malicious clients may modify =
the merchant_data, so should be authenticated in some way (for example, sig=
ned with a merchant-only key)."</span></div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span st=
yle=3D"line-height:1.5em"></span></div><div><span style=3D"line-height:1.5e=
m">=A0 =A0"</span><span style=3D"line-height:19.200000762939453px;font=
-size:12.800000190734863px;font-family:sans-serif">PaymentDetails.payment_u=
rl must be secure against man-in-the-middle attacks that might alter Paymen=
t.refund_to (if using HTTP, it must be TLS-protected).</span></div>
<div><br></div><div><font color=3D"#000000" face=3D"sans-serif"><span style=
=3D"line-height:19.1875px">This says "must", but what should a cl=
ient do here if the payment URL is not HTTPS? I suggest weakening this to &=
quot;should", as sometimes TLS is redundant (e.g. if you're sendin=
g to a Tor hidden service).</span></font></div>
</div></blockquote><div><br></div><div>done.</div><div>=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">
<div><span style=3D"line-height:19.1875px;font-family:sans-serif">The Payme=
ntACK message contains a copy of Payment, but the BIP doesn't say what =
to do with it. I assume this means a client is free to ignore it and rely o=
n TCP state to figure out the payment/ack connection instead? It may be wor=
th noting that explicitly.</span></div>
</div></blockquote><div><br></div><div>Added:</div><div><br></div><div>&quo=
t;payment | Copy of the Payment message that triggered this PaymentACK. Cli=
ents may ignore this if they implement another way of associating Payments =
with PaymentACKs."</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<div><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height=
:19.1875px"><br></span></font></div><div><font color=3D"#000000" face=3D"sa=
ns-serif"><span style=3D"line-height:19.1875px">In the certificates section=
, you could observe that "validation" means "verification th=
at it correctly chains to a trusted root authority, where trusted roots may=
be obtained from the operating system. If there is no operating system, th=
e Mozilla root store is recommended".</span></font></div>
<div><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height=
:19.1875px"></span></font></div></div></blockquote></div><div><br></div><di=
v>Modified that section to say:</div><div><br></div><div>"...<span sty=
le=3D"background-color:rgb(255,255,255);font-family:sans-serif;font-size:13=
px;line-height:19.1875px">followed by additional certificates, with each su=
bsequent certificate being the one used to certify the previous one, up to =
a trusted root authority. The recipient must verify the certificate chain a=
ccording to [RFC5280] and reject the PaymentRequest if any validation failu=
re occurs.</span></div>
<p style=3D"margin:0.4em 0px 0.5em;line-height:19.1875px;font-family:sans-s=
erif;font-size:13px;background-color:rgb(255,255,255)">Trusted root certifi=
cates may be obtained from the operating system; if validation is done on a=
device without an operating system, the=A0<a rel=3D"nofollow" class=3D"ext=
ernal text" href=3D"http://www.mozilla.org/projects/security/certs/included=
/index.html" style=3D"text-decoration:none;color:rgb(102,51,102);background=
-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs=
+9AAAAVklEQVR4Xn3PgQkAMQhDUXfqTu7kTtkpd5RA8AInfArtQ2iRXFWT2QedAfttj2FsPIOE1=
eCOlEuoWWjgzYaB/IkeGOrxXhqB+uA9Bfcm0lAZuh+YIeAD+cAqSz4kCMUAAAAASUVORK5CYII=
=3D);padding-right:13px;background-repeat:no-repeat no-repeat">Mozilla root=
store</a>=A0is recommended."</p>
<div><br></div>-- <br>--<br>Gavin Andresen<br>
--f46d044517f7bdfe7a04e2cce4b1--
|
