From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CFCB74 for ; Fri, 25 Mar 2016 07:23:50 +0000 (UTC) X-Greylist: delayed 00:05:29 by SQLgrey-1.7.6 Received: from sasl.smtp.pobox.com (pb-smtp0.pobox.com [208.72.237.35]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35E5779 for ; Fri, 25 Mar 2016 07:23:49 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 23C8249B61 for ; Fri, 25 Mar 2016 03:18:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=ToxjRig9I5Uv fN9XIUBFqqoEQQQ=; b=lMfFKTknCn26mKSk2E7NCgN3KxNZnQOTiVOTM/iUx0Ai N1CjcvrmjgRpwDfZrcgBtgZjbBpocr15k7UkkFcszCgH2JDWyvyYYO15ere9QzI9 K4EhJg7zCOHamkwDTBKelrwqQNcBNWL/AF8PE0ghkOlArjKuX+XAfyrPHYxNhNk= Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 1CD0149B60 for ; Fri, 25 Mar 2016 03:18:19 -0400 (EDT) Received: from laptop-m1330 (unknown [173.30.28.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id 878CD49B5E for ; Fri, 25 Mar 2016 03:18:18 -0400 (EDT) Date: Fri, 25 Mar 2016 03:17:29 -0400 From: Lee Clagett To: Jonas Schnelli via bitcoin-dev Message-ID: <20160325031729.511ab37c@laptop-m1330> In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch> References: <56F2B51C.8000105@jonasschnelli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: BFACA632-F259-11E5-8ED5-E95C6BB36C07-92142693!pb-smtp0.pobox.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Fri, 25 Mar 2016 17:29:32 +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: Fri, 25 Mar 2016 07:23:50 -0000 On Wed, 23 Mar 2016 16:24:12 +0100 Jonas Schnelli via bitcoin-dev wrote: > Hi > > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 > > Two BIPs that addresses the problem of decoupling wallets/clients from > nodes while assuming a user (or a group) know the remote peer. > > Authentication would be necessary to selective allow bloom filtering > of transactions, encryption or any other node service that might lead > to fingerprinting or resource attacks. Authentication would also be a > pre-requirement for certificate free encryption-handshakes that is > (enough?) resistant to MITM attacks. > > Encryption is highly recommended if you connect a SPV node to a > trusted node. > > Authentication would allow accessing private p2p extensions from a > remote SPV peer (example: fee estimation). > > I'm aware of other methods to increase privacy and integrity (tor, > VPN, stunnel, etc.), however I think authentication and a basic > communication encryption should be part of the protocol and its setup > should be complete hassle-free. > > Thanks for your feeback. > > /jonas > - The motivation sections seem weak. Why not use SSH? It would have similar setup requirements, and is already a deployed solution. If there are additional setup simplicities (compared to SSH), consider listing them. And if one of the motivating factors is complexity reduction from the various "do everything you could possible want" protocols/implementations, then add this to the motivation. - ECDSA and "ec pubkey" are mentioned, but not the specific curve. - The hash algorithm for ECDSA is not explicitly mentioned. - There is no way to change the cryptographic primitives being used or to update to a new protocol version. Would it be done with a new message type `auth2` ... ? - The following seems to be contradictory: > If the responding peer could not lookup the requesting peer's > identity-pubkey in the local authorized-peers database or if the > responding peer could not verify the signature, the requested auth > message must be ignored to avoid fingerprinting of peers with > authentication support. > > Responding peers must ignore (banning would lead to fingerprinting) > the requesting peer after 5 unsuccessfully authentication tries to > avoid resource attacks. If I connect to a peer, send 5 auth messages followed by another type of message that gets no response, this could indicate auth support. Or is this supposed to say ignore further auth messages, but not other types of messages? The wording seems to suggest an ignore-all. - The pubkey from the requester is sent in cleartext, which can be used as an identifier across connections (similar to a MAC, except it can be seen across every network hop and correlated across connection types). Hiding this will likely require encryption, and the protocol will start to look similar to CurveCP. If the additional complexity is not worth fixing this issue, a section in the encryption BIP should be added to explain the identifier leakage. - The known-peers has an IP and port section. Should the requester limit signatures based on this information? This algorithm or process needs to be better defined than the vague paragraph about verifying the integrity of the remote peer; if an implementation uses the any-one-of server approach the known-peers file becomes more like a SSL CA list, which does not seem like the intent. However, the example at the bottom says "Requesting peer does a lookup of (F) in known-peers database (B)". - The encryption portion does not mention the pubkey pairs in use for ECDH (this needs to be described), so I am assuming the pairs from authentication are re-used. This increases the chances of data exposure since a single botched k selection (re-use) for ECDSA would allow for forged authentications, and the decryption of all historical data. Adding a temporary key exchange would add slight complexity and one RTT from the requesters perspective, but it provides forward-secrecy and protection against ECDSA implementation failures. - Can the responding peer set a different cipher in the `ecinit` response, or should/must it be the same? - What happens if the responding peer does not support the cipher? Presumably, a rejection? - The contents of the IV field are unspecified, and should be specified to contain new output from a CSPRNG for each message. - Should `enc` messages be wrapped in `auth` messages (presumably so since there is no MAC)? `encinit` have this restriction, but nothing is specified for `enc`. - Is the context hash unique in each direction? There seems to be one, which would be racy - what if the client wanted to pipeline messages? Or is the intent a single open request/response style? I think this _adds_ a restriction to the Bitcoin protocol. - Instead of a hash, what about a counter in each direction for the `enc` stream? The auth portion verifies integrity, authenticity, and completeness of each message (including this counter). Missing messages (through TCP injection?) would still detected. Using TCP injection to forcefully teardown a connection is possible in both designs. Lee