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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 38022A18
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 15:22:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3C83206
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 15:22:11 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id a66so123731934wme.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jun 2016 08:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=Ymo6XZ5D3BcfFIJao2Dfj728rApTmFl9Xs9qkxPMobs=;
b=pTpkeYhNRxKSsQgxg8HyVUpYV/Wj3cIpuOPslridfj0UR6oJd+C94lFPehyZvyGAGv
QKqmtGc6YCuUl+hK48O9NB7HwY75DocbW98lwo5wo3OjKjpP2JCkVrUfL70D6n4TFola
htyP4G1nW0e1i/1VhZF1iYzhoDVsWP6WlwVLDDHPhjLA0O/KUXVmm4oY4sE6RsZR2Zxm
521Zdh2HMgrIdGzG00CGvx3UIQp2yk9v1WsBCvoIRuNyzzCsfQGLPa0ZxqxycsQ9W+vl
N55oiGHoqqgmnTwDCLFDBvYJIDtpP6E0Z2fu/lKI9gip9vdYG81CJFe50MePo7j+uBRT
uVSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=Ymo6XZ5D3BcfFIJao2Dfj728rApTmFl9Xs9qkxPMobs=;
b=IjAZ2Nx3wT3ar+OL3NUYD2OcahiGk8f3fyior29w6PP4HzITDloy/t7oQ0wtb+Wo0+
jc+Q4/WyBRzMHLJAPyfwBq5T/LJW5ZaN8pOD8/ilUu/tz+QXyHWgZfwlVEqtemteF1i1
dyIMyyh6CHQYM7PoJ9+g9vQUSdFLmaReN2OhxUSRB6ckMnJfn/7OS11EY1IY8XZdLOTq
YkhxmBkmikey3x/z2uKbcW3LNUm1LUO/wqcNccj2jIBCBJN8qPK6S30nnN/re0rCEXLg
5K89OHo/oeUFksur+qcK+R95ZBfWWRyVuFSkhYkrex0yuvh1u33OFpRpwjt6ywOqRCOk
PyTw==
X-Gm-Message-State: ALyK8tI0M8UJ2kpUGiIax2iQ9sIkfN+Eov8PgjzjMNAxu5KRzIThuWSBhq5XKntuxNdsjw==
X-Received: by 10.194.176.132 with SMTP id ci4mr14299109wjc.138.1467300130551;
Thu, 30 Jun 2016 08:22:10 -0700 (PDT)
Received: from [197.161.188.155] ([197.161.188.155])
by smtp.gmail.com with ESMTPSA id s67sm4867886wmf.3.2016.06.30.08.22.09
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 30 Jun 2016 08:22:09 -0700 (PDT)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <577513DB.60101@jonasschnelli.ch>
Date: Thu, 30 Jun 2016 17:22:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4BDD091-FD80-4EE9-93EF-735B6BBE253C@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
<577234A4.3030808@jonasschnelli.ch>
<360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
<20160629111728.GO13338@dosf1.alfie.wtf>
<2981A919-4550-4807-8ED9-F8C51B2DC061@voskuil.org>
<57750EAB.3020105@jonasschnelli.ch>
<426C2AA3-BFB8-4C41-B4DF-4D6CC11988B2@voskuil.org>
<577513DB.60101@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 15:22:13 -0000
> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <dev@jonasschnelli.ch> wrote:
>=20
>>>> The core problem posed by BIP151 is a MITM attack. The implied solution=
(BIP151 + authentication) requires that a peer trusts that another is not a=
n attacker.
>>>=20
>>> BIP151 would increase the risks for MITM attackers.
>>> What are the benefits for Mallory of he can't be sure Alice and Bob may
>>> know that he is intercepting the channel?
>>=20
>> It is not clear to me why you believe an attack on privacy by an anonymou=
s peer is detectable.
>=20
> If Mallory has substituted the ephemeral keys in both directions, at the
> point where Alice and Bob will do an authentication, they can be sure
> Mallory is listening.
I understand the mechanics of a tunnel between trusting parties that have a s=
ecure side channel. But this assumes that no other peer can connect to these=
two nodes. How then do they maintain the chain?
The "middle" in this sense does not have to be the wire directly between the=
se two peers. It can be between either of them and any anonymous connection t=
hey (must) allow.
Of course this creates pressure to expand their tunnel. Hence the problem of=
expanding node identity in an effort to preserve privacy. The protection wi=
ll remain weak until the entire network is "secure". At that point it would n=
ecessarily be a private network.
As Pieter rightly observes, there are and always will be tunnels between tru=
sting nodes. Often these are groups of nodes that are in collaboration, so l=
ogically they are one node from a system security standpoint. But if people b=
ecome generally reliant on good node registration, it will become the regist=
rar who controls access to the network. So my concern rests I this proposal b=
ecoming widely adopted.
> Simple dummy example:
> 1.) Encryption setup with ECDH with ephemeral keys after BIP151
> 2.) Mallory is MITMling the connection. He is substituting both direction w=
ith its own keys
> 3.) Connection is successfully MITMled
> 4.) Alice tells Bob "prove me that you are Bob, please sign the session-ID=
with your identity key"
> 5.) Bob signs the sessionID (ECDH secret) with his identity key which
> will be unusable for Mallory who has a substituted sessionID in both direc=
tions.
> 6.) Alice has successfully detected the Mallory
>=20
> Disclaimer: 4) and 5) are _not_ authentication proposals :-)
>=20
> </jonas>
>=20
|
