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-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1XSRE6-00012P-B7
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Sep 2014 13:49:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.41 as permitted sender)
client-ip=209.85.218.41; envelope-from=mh.in.england@gmail.com;
helo=mail-oi0-f41.google.com;
Received: from mail-oi0-f41.google.com ([209.85.218.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XSRE5-0000Zp-7q
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Sep 2014 13:49:26 +0000
Received: by mail-oi0-f41.google.com with SMTP id u20so506131oif.14
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Sep 2014 06:49:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.52.197 with SMTP id v5mr2356198obo.85.1410529759701;
Fri, 12 Sep 2014 06:49:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.22.108 with HTTP; Fri, 12 Sep 2014 06:49:19 -0700 (PDT)
In-Reply-To: <luuk5f$i8o$1@ger.gmane.org>
References: <mailman.341412.1410515709.2178.bitcoin-development@lists.sourceforge.net>
<A4CC413B-D5A5-423C-9D56-463FCDBDDE08@coinqy.com>
<luuk5f$i8o$1@ger.gmane.org>
Date: Fri, 12 Sep 2014 15:49:19 +0200
X-Google-Sender-Auth: -E9rDjVVscKWemmVCoGWnll3i1U
Message-ID: <CANEZrP1iTfZxY915hzoAEApz1+wd_S9j5RCwVJCNFqQ_+DNTSQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=089e0158b0d845b2f30502de8d29
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: 1XSRE5-0000Zp-7q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP72 amendment proposal
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: Fri, 12 Sep 2014 13:49:26 -0000
--089e0158b0d845b2f30502de8d29
Content-Type: text/plain; charset=UTF-8
A few thoughts on this:
(1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
here is that a MITM intercepts the payment request, which will be typically
requested just seconds after the QR code is vended. 80 bits of entropy
would still be a lot and take a long time to brute force, whilst keeping QR
codes more compact, which impacts scannability.
(2) This should *not* be necessary in the common HTTPS context. The QR code
itself is going to be fetched from some service, over HTTPS. I see no
reasonable attacker that can MITM the request for the BIP70 message but not
the request to get the QR code. Adding a hash makes QR codes more bloated
and harder to scan, all on the assumption that HTTPS is broken in some odd
way that we haven't actually ever seen in practice.
(3) This can be useful in the Bluetooth context, but then again, we could
also do things a different way by signing with the key in the first part of
the URI, thus avoiding the need for a hash.
I know I've been around the loop on this one with Andreas many times. But
this BIP doesn't fix any actually existing problem in the previous spec. It
exists because Andreas thinks SSL is useless. If SSL is useless we all have
much bigger problems.
--089e0158b0d845b2f30502de8d29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A few thoughts on this:<div><br></div><div>(1) Base64 of S=
HA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MI=
TM intercepts the payment request, which will be typically requested just s=
econds after the QR code is vended. 80 bits of entropy would still be a lot=
and take a long time to brute force, whilst keeping QR codes more compact,=
which impacts scannability.</div><div><br></div><div>(2) This should <b>no=
t</b>=C2=A0be necessary in the common HTTPS context. The QR code itself is =
going to be fetched from some service, over HTTPS. I see no reasonable atta=
cker that can MITM the request for the BIP70 message but not the request to=
get the QR code. Adding a hash makes QR codes more bloated and harder to s=
can, all on the assumption that HTTPS is broken in some odd way that we hav=
en't actually ever seen in practice.</div><div><br></div><div>(3) This =
can be useful in the Bluetooth context, but then again, we could also do th=
ings a different way by signing with the key in the first part of the URI, =
thus avoiding the need for a hash.</div><div><br></div><div>I know I've=
been around the loop on this one with Andreas many times. But this BIP doe=
sn't fix any actually existing problem in the previous spec. It exists =
because Andreas thinks SSL is useless. If SSL is useless we all have much b=
igger problems.</div></div>
--089e0158b0d845b2f30502de8d29--
|
