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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy.spilman@gmail.com>) id 1UVRb1-0005lr-Lb
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 19:12:43 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.171 as permitted sender)
client-ip=209.85.220.171; envelope-from=jeremy.spilman@gmail.com;
helo=mail-vc0-f171.google.com;
Received: from mail-vc0-f171.google.com ([209.85.220.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UVRb0-0002eb-QP
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 19:12:43 +0000
Received: by mail-vc0-f171.google.com with SMTP id ha12so563454vcb.16
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 12:12:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.58.173.36 with SMTP id bh4mr13760245vec.9.1366917157280;
Thu, 25 Apr 2013 12:12:37 -0700 (PDT)
Received: by 10.58.137.197 with HTTP; Thu, 25 Apr 2013 12:12:37 -0700 (PDT)
In-Reply-To: <CANEZrP0FS5CZaqEEwCZM-nfPB9D2TfC_moX3BE+TEnfWtc=aOg@mail.gmail.com>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
<20130425095855.GA30535@crunch>
<CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
<20130425102853.GA31573@crunch>
<CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
<FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
<CANEZrP0FS5CZaqEEwCZM-nfPB9D2TfC_moX3BE+TEnfWtc=aOg@mail.gmail.com>
Date: Thu, 25 Apr 2013 12:12:37 -0700
Message-ID: <CA+CODZFpS2DWaC0KRghymOXKQdNhhxAty_5eW0XZJ8Sg5s1bGQ@mail.gmail.com>
From: Jeremy Spilman <jeremy.spilman@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b5da81398e47204db343340
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
(jeremy.spilman[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: 1UVRb0-0002eb-QP
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: Thu, 25 Apr 2013 19:12:43 -0000
--047d7b5da81398e47204db343340
Content-Type: text/plain; charset=ISO-8859-1
There are definitely ways to keep the pay-to address secure even if the web
server is compromised, just perhaps not perfectly clean standard X.509 ways
under the current ecosystem which would be easier for everyone to agree on.
- If a more trusted cert is an EV end cert, and a less trusted is a DV end
cert (not chained off the EV) then it's easy for the wallet to distinguish
between the two, and they are both valid certs. EV signs pubKey offline, DV
used hot on the web server.
- If the more trusted cert is an EV or DV end cert, and the less trusted
cert is chained off that end cert, it's technically 'invalid' so again its
obvious which one is more/less trusted, but it's easier for an attacker to
get their own DV end cert for your domain.
- The third way is getting the pubKey into the cert attributes, such as
encoding the pubKey, or a fingerprint of the pubKey, as a Subject Alternate
Name, so the attacker would need to get their own cert to change the
address, meaning it's not as critical if your cert key is stolen.
On the wallet side, it comes down to additional validation code paths which
get triggered by some detection logic. For example, if you pass PubKey and
InvoiceID in the Payment Request, the wallet needs to know if it should
check for a Subject Alternate Name in the cert for a fingerprint of the
PubKey, how the fingerprint is calculated, and then verify the Address is
indeed PubKey * InvoiceID. I think falsely rejecting a legacy Payment
Request would get the extra validation code path commented out pretty
quickly.
I really like Mike Hearn's idea of 'You have paid this recipient 4 times'
but also agree completely on the crying wolf due to expiration or
revocation. At least such a message could be based on the domain name only,
to try to prevent phishing with similar domain names, then there's no
expiration issue. Slightly more restrictive would be domain + CA, again not
considering expiration, but pinning the pay count to the CA seems to have
little downside and makes it harder for an attacker to get their own cert
for your domain if you choose your CA 'wisely'.
I assume the ship has sailed on v1, but if we can get consensus on how we
want this to work in the near-term, we can start prototyping it and maybe
get this available sooner than later. In any case we should be confirm v1
doesn't do anything to prevent this from working in a clean, extensible
manor, which I think means prototyping it and seeing the new Payment
Request is handled transparently by v1 code.
Right now I'm leaning towards writing a prototype using a single cert with
a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
and InvoiceID in the Payment Request. Gavin, would the best way to work on
this be to just fork your code on Github?
Thanks,
--Jeremy
--047d7b5da81398e47204db343340
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There are definitely ways to keep the pay-to address secur=
e even if the web server is compromised, just perhaps not perfectly clean s=
tandard X.509 ways under the current ecosystem which would be easier for ev=
eryone to agree on.<div>
<br></div><div style>=A0- If a more trusted cert is an EV end cert, and a l=
ess trusted is a DV end cert (not chained off the EV) then it's easy fo=
r the wallet to distinguish between the two, and they are both valid certs.=
EV signs pubKey offline, DV used hot on the web server.</div>
<div style>=A0- If the more trusted cert is an EV or DV end cert, and the l=
ess trusted cert is chained off that end cert, it's technically 'in=
valid' so again its obvious which one is more/less trusted, but it'=
s easier for an attacker to get their own DV end cert for your domain.<br>
</div><div style>=A0- The third way is getting the pubKey into the cert att=
ributes, such as encoding the pubKey, or a fingerprint of the pubKey, as a =
Subject Alternate Name, so the attacker would need to get their own cert to=
change the address, meaning it's not as critical if your cert key is s=
tolen.<br>
</div><div style><br></div><div style>On the wallet side, it comes down to =
additional validation code paths which get triggered by some detection logi=
c. For example, if you pass PubKey and InvoiceID in the Payment Request, th=
e wallet needs to know if it should check for a Subject Alternate Name in t=
he cert for a fingerprint of the PubKey, how the fingerprint is calculated,=
and then verify the Address is indeed PubKey * InvoiceID. =A0I think false=
ly rejecting a legacy Payment Request would get the extra validation code p=
ath commented out pretty quickly.</div>
<div style><br></div><div>I really like Mike Hearn's idea of 'You h=
ave paid this recipient 4 times' but also agree completely on the cryin=
g wolf due to expiration or revocation. At least such a message could be ba=
sed on the domain name only, to try to prevent phishing with similar domain=
names, then there's no expiration issue. Slightly more restrictive wou=
ld be domain + CA, again not considering expiration, but pinning the pay co=
unt to the CA seems to have little downside and makes it harder for an atta=
cker to get their own cert for your domain if you choose your CA 'wisel=
y'.</div>
<div style><br></div><div style>I assume the ship has sailed on v1, but if =
we can get consensus on how we want this to work in the near-term, we can s=
tart prototyping it and maybe get this available sooner than later. In any =
case we should be confirm v1 doesn't do anything to prevent this from w=
orking in a clean, extensible manor, which I think means prototyping it and=
seeing the new Payment Request is handled transparently by v1 code.</div>
<div style><br></div><div style>Right now I'm leaning towards writing a=
prototype using a single cert with a fingerprint of PubKey in the Subject =
Alternate Name, and getting PubKey and InvoiceID in the Payment Request. =
=A0Gavin, would the best way to work on this be to just fork your code on G=
ithub?</div>
<div style><br></div><div style>Thanks,</div><div style>--Jeremy</div></div=
>
--047d7b5da81398e47204db343340--
|
