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 39877F0B for ; Fri, 7 Sep 2018 08:34:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch [138.201.55.219]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2BF4BA8 for ; Fri, 7 Sep 2018 08:34:23 +0000 (UTC) Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002) id 0A0FD15E1A0E; Fri, 7 Sep 2018 10:34:22 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from [192.168.0.9] (cable-static-239-93.teleport.ch [213.188.239.93]) by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 43E9E15E0C2C; Fri, 7 Sep 2018 10:34:20 +0200 (CEST) From: Jonas Schnelli Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7C2FE18C-31D5-4AC5-B41C-B992D83E1331"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 7 Sep 2018 10:34:13 +0200 In-Reply-To: <061aa38d8ceeb6caaae19d7c86e435a5f86b293b.camel@timruffing.de> To: Tim Ruffing References: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> <061aa38d8ceeb6caaae19d7c86e435a5f86b293b.camel@timruffing.de> X-Mailer: Apple Mail (2.3445.9.1) X-Virus-Scanned: clamav-milter 0.100.1 at bitcoinsrv.jonasschnelli.ch X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 07 Sep 2018 13:45:08 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Overhauled BIP151 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: Fri, 07 Sep 2018 08:34:24 -0000 --Apple-Mail=_7C2FE18C-31D5-4AC5-B41C-B992D83E1331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tim Thanks for the feedback. I agree with all of Gregs answers. > key. Together with the encrypted packet lengths, the entire data = stream looks like random then, > which is pretty useful against censorship resistance for example. (The = only exception is that the > stream will never start with the magic bytes.) All-or-none censorship attacks are out of scope for BIP151. We won=E2=80=99t achieve DPI robustness in this proposal and I think it = should not be part of the p2p protocol. I think all-or-one censorship situations require an additional layer = like TOR with OBFS4 (where AFAIK Eligator is used). Eventually Core does directly support non-tor routed pluggable = transports (it's partially already possible via SOCK proxy, but not on a = gossip and plugin-launch level). This does not exclude that we should obfuscate the key exchange as good = as we can without blowing up the implementation too much. The proposed encryption adds a robustness to the thread model with very = little costs and low risks. > "salt =3D BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" = should just avoid this issue. This is a good point and I=E2=80=99d like to see more concrete examples = how this (the non dynamic salt) could be exploited. > Re-keying > =3D=3D=3D=3D=3D=3D=3D=3D=3D > The problem with signalling re-keying in the length field is that the = length field is not covered > by the MAC. So the attacker can flip the signalling bit. The resulting = protocol is probably still > secure but the malleability is certainly not desirable. In ChaCha20Poly1305@openssh, the length field is AAD, encrypted with a = different key and part of the MAC. >=20 > Deterministic rekeying rules may be better. Otherwise there will be = implementations that rekey > every 10 seconds and implementations that just don't rekey at all = (rendering the 10 s rekeying > interval in the opposite direction useless). Different policies also = make it possible to > fingerprint implementations. Another problem is that people will set = their policies arbitrarily. > What's better: 5 min or 30 min? I don't know, but both are reasonable = choices. (Thats's very much > like discussions about ciphers... What's better AES-GCM or = ChaCha20/Poly1305? I don't know, but > again both are reasonable choices.) The Rekey cost is two times a double-SHA256,=E2=80=A6 the costs of a = rekey is similar to one or two v1 INV message creations. >=20 > Symmetric crypto > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > You call it chacha20-poly1305@bitcoin but what's the difference to the = openssh then? Is the > idea to save a call to chacha here as you mentioned? >=20 > I didn't think about this in detail: maybe there are a few meaningful = cases where padding could > hide the message length without too much overhead. (I'm not convinced, = just a random thought.) I think a new message type that could contain message + pad would be = trivial. Would this again be to obfuscate traffic patterns? Anti DPI is not the = scope of BIP151. >=20 > Misc > =3D=3D=3D=3D > "The ID/string mapping is a peer to peer arrangement and MAY be = negotiated between the > requesting and responding peer." I think that's overly complicated. I = suggest it should just be > written in stone, again to avoid complexity and to avoid = fingerprinting. New implementations are > necessary anyway, so maybe just use IDs for anything? ASCII is nice if = you want to debug your code > or some random network failure but that's hard anyway when encryption = is used. I wanted to avoid too much central planing here and only cover the ones = where it's most efficient (small messages that are used often). The ASCII commands are in itself somehow pseude-robust against = collision. For a 1MB block message, using a 1-byte short ID (rather then a 6-byte = ASCII command) would reduce the bandwidth requirement insignificant = (99.99952%). If we would always have used short IDs in the past, there could have = been a collision between XTIN, compact, sendheaders or so. >=20 > In general, the entire thing is a little bit underspecified. (I'm = aware it's just a draft.) > A few examples: > - What should a peer do if the MAC verification fails? > - What should a peer do if it receives an even key? > - "Processing the message before the authentication succeeds (MAC = verified) MUST not be done." > That should also apply to the ciphertext. (Or: What is a "message"?). = It may be a good idea to > to refer to the openssh document or steal from it; it does a pretty = good job. > - "Both peers MUST keep track of the message sequence number (uint32) = of sent and received > messages for building a 64-bit symmetric cipher IV." I think you mean = nonce when you say IV? > - What is the initial value of the sequence number? Good points. Will make them more clear in the BIP. I was under the false impression that it is obvious to disconnect in = those cases. > - How is a 64-bit nonce formed from one (two?) uint32? That=E2=80=99s specified in ChaCha20Poly1305@openssh ("a nonce = consisting of the packet sequence number encoded as a uint64=E2=80=9C). But I=E2=80=99ll specified that more clear. > - What if the uint32 overflows? The max data before rekey is 1GB, AFAIK it is impossible to overflow. > - "Re-Keying interval is a peer policy with a minimum timespan of 10 = seconds." What if I receive > too many re-keying requests? Nothing or should I raise the DoS score? Current implementation proposal does a disconnect. With the risk of = fingerprinting options, I think we can leave this open to the = implementation? > - "The Re-Keying must be done after every 1GB of data sent or = received" Hm, every peer updates its > own sending key, so this should just read "sent" instead of "sent or = received=E2=80=9C? Yes. Should probably be =E2=80=9Esent=E2=80=9C,=E2=80=A6 and eventually = a paragraph that states that a peer should disconnect if the remote peer = did not rekey within that limit. > Pseudocode could probably help here. Agree. Will try to add. --Apple-Mail=_7C2FE18C-31D5-4AC5-B41C-B992D83E1331 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAluSOAUACgkQHrd2uwPH ki0pHA/+N6kie3RK1GkGqV5ep49PoKfPldzbBtolAZTnMHdJBblQnzPN8c2SwF2J xjlhJ4qk6+k5CKMlOqNvxJQ0KJ9RKHgo0rAXlmh7VZu/SbWz7+YHgBg4qbJgd+MQ X1OvEv/xdoJeXssrpdplBKluY9kEJpkj30U5c8CtMC6n+C2TQEGuzBdFv9P+x+cE bjRfzSZ0ahs3wzu0je8o0klzjalyfScFMeCC+HhJgaKtigDDpJV+4nLW6MOXj8VP 2IXIfJXuOKE5PYVSky/4VDqMyNQjhbZlJunLza0+XQXjEWN62NVeJUIO2jt9AvZZ h9nxQGx7gprfhCCMp6VoCvfBsZ6ZMRslQsCDEckIzfd2Yr7Qp7U3oiDJn3ogDbr8 o5VEJ+qq9fUpKJaxw1E+1UkBL9u5Qg6WAqz+GQDtOj4MUZOuVY01o+lW7L2GRCVm J3WC0J6Jd+HoiarckYrOytalcZVLW0vI3N2H70cf7LLch474FGg9oBzr19QxDsuR XMsWyZmQr8EybzAzhtCUsNAq5CZ8dZDdZKCQ+wMt2KlJ0Ti4/KAF7ERr/b8aUTGj NQ/2+QqqYKEadXQnDftznf71exVmNFsRvrwWT8WofVK/hnGiqdg+J/+LUTV1foVb MyDVzyUEcPqmsX7bRbL7Ff0nTvFxEzvf180whApKii7Vyg5AD1Y= =yCUl -----END PGP SIGNATURE----- --Apple-Mail=_7C2FE18C-31D5-4AC5-B41C-B992D83E1331--