Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 38022A18 for ; 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 ; Thu, 30 Jun 2016 15:22:11 +0000 (UTC) Received: by mail-wm0-f47.google.com with SMTP id a66so123731934wme.0 for ; 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 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: 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:22:13 -0000 > On Jun 30, 2016, at 2:43 PM, Jonas Schnelli 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 > >=20