summaryrefslogtreecommitdiff
path: root/db/dd760f67251bc28b057eb72aea7e2394c0b070
blob: 66d52bd7a4a76958afbcbb58089576c3cfcf81d5 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1YPhSR-0007BG-5w for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 01:05:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
Received: from plane.gmane.org ([80.91.229.3])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YPhSQ-0007q0-3S
	for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 01:05:11 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
	id 1YPhSJ-0001ND-7t for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 02:05:03 +0100
Received: from f052012129.adsl.alicedsl.de ([78.52.12.129])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
	Mon, 23 Feb 2015 02:05:03 +0100
Received: from andreas by f052012129.adsl.alicedsl.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 23 Feb 2015 02:05:03 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 23 Feb 2015 02:02:03 +0100
Message-ID: <mcdu6b$j11$1@ger.gmane.org>
References: <20150222190839.GA18527@odo.localdomain>	<54EA5A1C.2020701@AndySchroder.com>
	<54EA60D9.8000001@voskuil.org> <54EA66F5.2000302@AndySchroder.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052012129.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.4.0
In-Reply-To: <54EA66F5.2000302@AndySchroder.com>
X-Spam-Score: -0.4 (/)
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 SPF_HELO_PASS          SPF: HELO matches SPF record
	1.1 DKIM_ADSP_ALL          No valid author signature,
	domain signs all mail
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1YPhSQ-0007q0-3S
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
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: Mon, 23 Feb 2015 01:05:11 -0000

On 02/23/2015 12:32 AM, Andy Schroder wrote:
> I guess we need to decide whether we want to consider NFC communication
> private or not. I don't know that I think it can be. An eavesdropper can
> place a tiny snooping device near and read the communication. If it is
> just passive, then the merchant/operator won't realize it's there. So, I
> don't know if I like your idea (mentioned in your other reply) of
> putting the session key in the URL is a good idea?

I think the "trust by proximity" is the best we've got. If we don't
trust the NFC link (or the QR code scan), what other options have we
got? Speaking the session key by voice? Bad UX, and can be eavesdropped
as well of course.