path: root/f4/6ed069bbadd4fb5692d327ef0126497cef3ebc

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 39877F0B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <dev@jonasschnelli.ch>
Message-Id: <AA90A688-1419-450D-A80D-03469226BBE6@jonasschnelli.ch>
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 <crypto@timruffing.de>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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--