commit 0b25a60489d090e4abbcc7d0ba6370fca3121490
parent a5befe72ecd2e90797b2c4677d33ef9089dcb4e3
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Thu, 13 Jun 2024 17:03:32 +0200
Updated TCP communicator rekeying
Diffstat:
1 file changed, 157 insertions(+), 8 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -576,7 +576,7 @@ DeriveKID(MSK,SEQ):
]]></artwork>
</figure>
</section>
- <section anchor="tcp_rekeying" numbered="true" toc="default">
+ <section anchor="udp_rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>
(FIXME: rekeying procedure documentation is missing)
@@ -931,7 +931,12 @@ DeriveKID(MSK,SEQ):
<name>Key exchange</name>
<t>
During the initial handshake, each communication channel performs an X25519-based KEM, which provides the key material
- for the use of AES-CTR and HMAC-SHA512. The TCP communicator doesn't follow the standard X25519-KEM as described in
+ for the use of AES-CTR and HMAC-SHA512. Later, further key exchanges are performed during each rekeying process. More
+ about the initial handshake and rekeying can be found in <xref target="tcp_handshake"/> and
+ <xref target="tcp_rekeying"/> respectively.
+ </t>
+ <t>
+ The TCPcommunicator doesn't follow the standard X25519-KEM as described in
section 6.1 of <xref target="RFC7748"/> because Curve25519 public keys are recognisable by an outside observer. In a
censored environment, this could lead to the interception of such messages and ultimately prevent communication
between peers. We circumvent this issue by encoding public keys using Elligator, a mathematical method to encode curve points
@@ -993,11 +998,12 @@ SetupCipher(MSK):
The HMAC utilizes SHA512 as the underlying hash function and is ratcheted after each operation. Given the mac-then-encrypt
approach, additional safeguards are needed to protect against oracle padding attacks. Therefore, we <bcp14>MUST</bcp14> use
a padding free encryption scheme such as AES-CTR for encryption. Additionally, we restrict the attacker's ability for replay
- attacks by exchanging new key material after a fix amount of transferred data (FIXME: currently 4GB, refer to rekeying process).
- The necessary key exchanges to establish the new key material are protected using monotonic timestamps.
+ attacks by exchanging new key material after a randomly chosen amount of transferred data as described in
+ <xref target="tcp_rekeying"/>. The necessary key exchanges to establish the new key material are protected using monotonic
+ timestamps.
</t>
<t>
- (FIXME: hmac, MtE discussion, padding-oracle, rekeying).
+ (FIXME: hmac, MtE discussion, padding-oracle).
</t>
<figure anchor="figure_tcp_box" title="The binary representation of the tcp box packet.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1026,7 +1032,7 @@ SetupCipher(MSK):
<dt>TYPE</dt>
<dd>
A 16-bit signature type flag in network byte order. The value of this
- field <bcp14>MUST</bcp14> be XXXX (FIXME: Value missing).
+ field <bcp14>MUST</bcp14> be 1451.
</dd>
<dt>HASHCODE</dt>
<dd>
@@ -1035,11 +1041,154 @@ SetupCipher(MSK):
</dl>
</section>
- <section anchor="udp_rekeying" numbered="true" toc="default">
+ <section anchor="tcp_rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>
- (FIXME: documentation missing)
+ After each key exchange, up to 400 MB of data is transferred until rekeying is triggered by the sender of the communication direction.
+ The actual amount of transferred data <bcp14>SHOULD</bcp14> be chosen randomly. If the chosen byte quantity is not reached after
+ one day, rekeying is set off anyway.
+ </t>
+ <t>
+ The receiving communicator is signaled about a rekeying through the dispatch of a TCP Rekey packet as defined in
+ <xref target="figure_tcp_rekey"/>. The packet <bcp14>MUST</bcp14> be encrypted with the current key. Due to the encryption of the packet,
+ the encoding of the new ephemeral public key with Elligator is not needed. Similarly to the initial handshake, the ephemeral public key
+ is used to perform a key exchange from which new key material for the encryption and authentication code scheme are derived. For further
+ details please refer to <xref target="tcp_KEM"/>. Note that rekeying process is not acknowledged by the receiver, so the sender might send
+ new payload encrypted by the new key right after sending the TCP Rekey packet.
</t>
+ <figure anchor="figure_tcp_rekey" title="The binary representation of the TCP Rekey packet.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | TYPE (0x0X) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| HASHCODE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EPHEMERAL PUBLIC KEY |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| MONOTONIC TIMESTAMP |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <dl>
+ <dt>SIZE</dt>
+ <dd>
+ A 16-bit value containing the length of the message in bytes
+ in network byte order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ A 16-bit signature type flag in network byte order. The value of this
+ field <bcp14>MUST</bcp14> be 1450.
+ </dd>
+ <dt>HASHCODE</dt>
+ <dd>
+ A 256-bit HMAC-SHA512 hashcode of this TCP Rekey packet. The hashcode is
+ computed with the hashcode field initially set to zero and is inserted afterward.
+ </dd>
+ <dt>EPHEMERAL PUBLIC KEY</dt>
+ <dd>
+ A 256-bit Curve25519 public key which is used as part of an X25519-based
+ key exchange to establish a shared secret.
+ </dd>
+ <dt>Signature</dt>
+ <dd>
+ A 512-bit EdDSA signature. The signature is calculated over
+ the data as defined in <xref target="figure_tcp_rekey_sig"/>.
+ </dd>
+ <dt>MONOTONIC TIMESTAMP</dt>
+ <dd>
+ FIXME.
+ </dd>
+ </dl>
+ <figure anchor="figure_tcp_rekey_sig" title="The wire format used for creating the signature of the TCP Rekey packet.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE (0x0X) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SENDER PEER ID |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| RECEIVER PEER ID |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EPHEMERAL PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| MONOTONIC TIMESTAMP |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <dl>
+ <dt>SIZE</dt>
+ <dd>
+ A 32-bit value containing the length of the signed data in bytes
+ in network byte order.
+ </dd>
+ <dt>PURPOSE</dt>
+ <dd>
+ A 32-bit signature purpose flag in network byte order. The value of this
+ field <bcp14>MUST</bcp14> be 32. It defines the context in which
+ the signature is created so that it cannot be reused in other parts
+ of the protocol including possible future extensions.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purpose" registry <xref target="gana"/>.
+ </dd>
+ <dt>SENDER PEER ID</dt>
+ <dd>
+ A 256-bit EdDSA public key.
+ </dd>
+ <dt>RECEIVER PEER ID</dt>
+ <dd>
+ A 256-bit EdDSA public key.
+ </dd>
+ <dt>EPHEMERAL PEER ID</dt>
+ <dd>
+ A 256-bit EdDSA public key.
+ </dd>
+ <dt>MONOTONIC TIMESTAMP</dt>
+ <dd>
+ FIXME.
+ </dd>
+ </dl>
</section>
</section>
<section anchor="quic_comm" numbered="true" toc="default">
