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
|
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 <mh.in.england@gmail.com>) id 1YIkba-0003iN-Sr
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Feb 2015 21:01:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.45 as permitted sender)
client-ip=74.125.82.45; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f45.google.com;
Received: from mail-wg0-f45.google.com ([74.125.82.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YIkbZ-0006EF-5Y
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Feb 2015 21:01:54 +0000
Received: by mail-wg0-f45.google.com with SMTP id x12so46865283wgg.4
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Feb 2015 13:01:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.101.65 with SMTP id fe1mr16406250wib.66.1422997307117;
Tue, 03 Feb 2015 13:01:47 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Tue, 3 Feb 2015 13:01:47 -0800 (PST)
In-Reply-To: <CAFVoEQQHVcY0Ad-4c2wnH+WF_7M-o5SNwVr-nce_9bQ794cwDQ@mail.gmail.com>
References: <etPan.54d0b945.46e87ccd.7f23@Williams-MBP>
<CAFVoEQQHVcY0Ad-4c2wnH+WF_7M-o5SNwVr-nce_9bQ794cwDQ@mail.gmail.com>
Date: Tue, 3 Feb 2015 22:01:47 +0100
X-Google-Sender-Auth: Hiiv9OwmNpMGiHlBJVjHQDggTkg
Message-ID: <CANEZrP29oJU1i5mN=TmxRsVk4m5mJy9jf-=4gYvRKRfq11pkBg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Weiss <adam@signal11.com>
Content-Type: multipart/alternative; boundary=f46d041826be01d8f0050e3561b5
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: 1YIkbZ-0006EF-5Y
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Will <will.madden@novauri.com>
Subject: Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin
malware
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, 03 Feb 2015 21:01:54 -0000
--f46d041826be01d8f0050e3561b5
Content-Type: text/plain; charset=UTF-8
>
> TREZOR like devices with BIP70 support and third party cosigning services
> are a solution I really like the sound of. I suppose though that adding
> BIP70 request signature validation and adding certificate revocation
> support starts to balloon the scope of what is supposed to be a very simple
> device though.
>
Yes, X.509 is ....... unfortunate. We'll have to wait and see how the
TREZOR team get on with implementing it. TREZOR doesn't have any OS at all
at the moment, so an implementation of PKIX will probably end up being
larger than their existing codebase.
That said, X.509 parsing is so security critical that the existing
codebases for it are by now pretty robust. Touch wood. So just having a
super stripped down OpenSSL implementation is probably good enough.
W.R.T revocation, BIP70 doesn't support this. If your private key leaks
you're currently hosed, identity wise, until the certificate expires. This
is obviously suboptimal. In a world where we all have infinite time and
resources the right fix will be to piggy back on an X.509 extension being
proposed in the browser world called "Must Staple". It's a bit in the
certificate flags that tell the client to expect a stapled OCSP response
and to hard-fail if none is provided. By requesting the CA set this flag
when you get your certificate issued, you sign up for more pain but more
security.
An OCSP stapling extension to BIP70 would probably not be very hard to
implement, but it'd be pointless today because the client has no idea
whether to expect it or not. The absence of a certificate changes the UI by
showing you a random Bitcoin address instead of a human readable name, but
the absence of stapled OCSP would not result in any UI change.
> Regardless, I think a standard for passing partially signed transactions
> around might make sense
>
I'm hoping that the hardware wallet world just standardises on the TREZOR
protocol. It's well designed and these devices all have fairly similar
capabilities.
--f46d041826be01d8f0050e3561b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div>TREZOR like devices with BIP70 support and thir=
d party cosigning services are a solution I really like the sound of.=C2=A0=
I suppose though that adding BIP70 request signature validation and adding=
certificate revocation support starts to balloon the scope of what is supp=
osed to be a very simple device though.</div></div></div></div></blockquote=
><div><br></div><div>Yes, X.509 is ....... unfortunate. We'll have to w=
ait and see how the TREZOR team get on with implementing it. TREZOR doesn&#=
39;t have any OS at all at the moment, so an implementation of PKIX will pr=
obably end up being larger than their existing codebase.=C2=A0</div><div><b=
r></div><div>That said, X.509 parsing is so security critical that the exis=
ting codebases for it are by now pretty robust. Touch wood. So just having =
a super stripped down OpenSSL implementation is probably good enough.</div>=
<div><br></div><div>W.R.T revocation, BIP70 doesn't support this. If yo=
ur private key leaks you're currently hosed, identity wise, until the c=
ertificate expires. This is obviously suboptimal. In a world where we all h=
ave infinite time and resources the right fix will be to piggy back on an X=
.509 extension being proposed in the browser world called "Must Staple=
". It's a bit in the certificate flags that tell the client to exp=
ect a stapled OCSP response and to hard-fail if none is provided. By reques=
ting the CA set this flag when you get your certificate issued, you sign up=
for more pain but more security.</div><div><br></div><div>An OCSP stapling=
extension to BIP70 would probably not be very hard to implement, but it=
9;d be pointless today because the client has no idea whether to expect it =
or not. The absence of a certificate changes the UI by showing you a random=
Bitcoin address instead of a human readable name, but the absence of stapl=
ed OCSP would not result in any UI change.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>Regardless, I think a standard for passing partially =
signed transactions around might make sense</div></div></div></div></blockq=
uote><div><br></div><div>I'm hoping that the hardware wallet world just=
standardises on the TREZOR protocol. It's well designed and these devi=
ces all have fairly similar capabilities.=C2=A0</div></div></div></div>
--f46d041826be01d8f0050e3561b5--
|
