Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E1B0369 for ; Thu, 24 Mar 2016 02:17:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 39D3F10A for ; Thu, 24 Mar 2016 02:17:18 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id A1EA338A17C7; Thu, 24 Mar 2016 02:16:57 +0000 (UTC) X-Hashcash: 1:25:160324:bitcoin-dev@lists.linuxfoundation.org::iBC2/37vkHJL/M=u:bU01E X-Hashcash: 1:25:160324:dev@jonasschnelli.ch::NUIjFHu346GhVB3k:AD1P From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Jonas Schnelli Date: Thu, 24 Mar 2016 02:16:55 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; ) References: <56F2B51C.8000105@jonasschnelli.ch> In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201603240216.56752.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 24 Mar 2016 02:23:51 +0000 Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 02:17:19 -0000 On Wednesday, March 23, 2016 3:24:12 PM Jonas Schnelli via bitcoin-dev wrote: > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 In the future, please submit BIP drafts to the mailing list for comment and initial peer review before opening a pull request (or requesting a BIP number assignment), per BIP 1. > Each peer that supports p2p authentication, must provide two user editable > databases (can be a simple record-per-line file). As long as the format of these databases is not standardised, it seems inappropriate to define *any* of this implementation detail in a BIP. > A peer can send an authenticate message by wrapping the desired message into > an auth-message-wrapper to the remote peer. How does a peer know what messages the other peer requires to be authenticated? > 33bytes || identity-pubkey || comp.-pubkey || The identity pubkey of the > requesting peer Seems a waste to include this with every single [authenticated] message... > 8bytes || auth-msg-id || int64 || up-counting auth-msg-id (0 to INT64MAX) Is this required to persist across connections/restarts/possibly complete reinstalls? Can the same auth-msg-id be used for multiple peers, so a message can be signed once and sent to all N peers? > Responding peers must ignore (banning would lead to fingerprinting) the > requesting peer after 5 unsuccessfully authentication tries to avoid > resource attacks. How does banning in this specific case enable fingerprinting as opposed to any other banning? > The peers should display the identity-pubkey as a identity-address to the > users, which is a base58-check encoded ripemd160(sha256) hash. If this is going to become a general-purpose identity system, I think more is needed than a simple EC keypair. At the very least, it should probably use a HD chain and use a new key for every signature (notice you already have auth- msg-id to use with this!). > This proposal is backward compatible. Non supporting peers will ignore the > auth message. ... and not process it at all? How is that backward compatible? > Encrypting traffic between peers is already possible with VPN, tor, stunnel, > curveCP or any other encryption mechanism on a deeper OSI level, however, > most mechanism are not practical for SPV or other DHCP/NAT environment and > will require significant knowhow in how to setup a secure channel. I don't see how Tor fails this criteria... > The responding peer will set a session timeout time-interval. The default > must be 1'800 seconds. What default? Is the timeout field optional? Why not simply require it? > This proposal is backward compatible. Non supporting peers will ignore the > enc* messages. How should the supporting peer handle the message being ignored? Luke