commit d3be28a5b8d0b6eda50239ca1a7c941fe5e739aa
parent 9e934ea6b0ee325364ff21724b26ef7058b731f1
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Mon, 10 Jun 2024 13:42:49 +0200
Added TCP Communicator message exchange
Diffstat:
1 file changed, 61 insertions(+), 5 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -685,7 +685,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>NONCE</dt>
<dd>
- A 256-bit random value used as a challenge to be signed in a TCP acknowledgment.
+ A 256-bit random value used as a challenge to be signed in a TCP handshake acknowledgment packet.
</dd>
</dl>
<t>
@@ -768,7 +768,7 @@ DeriveKID(MSK,SEQ):
</dl>
<t>
Upon reception of the ephemeral public key, the receiving TCP communicator carries out the decapsulation step of the
- KEM and retrieves the shared key material. The subsequently received TCP handshake packet is then decrypted and verified.
+ key exchange and retrieves the shared key material. The subsequently received TCP handshake packet is then decrypted and verified.
If the signature is invalid, the connection is dropped. (FIXME: Other checks such as sender peer identity etc needed).
In the case of a valid signature, the receiving TCP communicator sends its own TCP handshake packet to establish
shared key material for outgoing messages and also replies with an encrypted TCP handshake acknowledgment packet as defined
@@ -924,8 +924,7 @@ DeriveKID(MSK,SEQ):
<t>
The initiating TCP communicator also replies with a TCP handshake acknowledgement packet after receiving
a valid TCP handshake packet. Lastly, each party verifies both the signature and the challenge within the received
- TCP handshake acknowledgement packet, thus completing the handshake. Once the handshake is finished, actual payloads
- can be exchanged bi-directionally using TCP Box messages. (FIXME: hmac, MtE discussion, padding-oracle, etc).
+ TCP handshake acknowledgement packet, thus completing the handshake.
</t>
</section>
<section anchor="tcp_KEM" numbered="true" toc="default">
@@ -974,7 +973,64 @@ SetupCipher(MSK):
and X25519-based KEM is proven to be secure. For more comprehensive information, please refer to the paper [T21].
</t>
</section>
- </section>
+ <section anchor="message_exchange" numbered="true" toc="default">
+ <name>Message exchange</name>
+ <t>
+ Once the handshake is completed actual payloads can be exchanged bi-directionally using TCP Box messages. A TCP Box message
+ consists of a TCP Box packet as defined in <xref target="figure_tcp_box"/>, followed by the payload. Both parts are encrypted
+ before being sent to the receiving peer.
+ </t>
+ <t>
+ TCP Box messages follow the mac-then-encrypt approach to hide the size of the payload and achieve a zero-plaintext design.
+ The receiving peer needs to decrypt both the TCP Box packet and the payload first before initiating the verification of the
+ hmac.
+ </t>
+ <t>
+ (FIXME: hmac, MtE discussion, padding-oracle, rekeying).
+ </t>
+ <figure anchor="figure_tcp_box" title="The binary representation of the tcp box packet.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | TYPE (0x0X) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| HASHCODE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+
+ ]]></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 XXXX (FIXME: Value missing).
+ </dd>
+ <dt>HASHCODE</dt>
+ <dd>
+ A 256-bit computed hmac for the subsequently sent payload.
+ </dd>
+ </dl>
+ </section>
+
+ <section anchor="rekeying_process" numbered="true" toc="default">
+ <name>Rekeying process</name>
+ <t>
+ (FIXME: documentation missing)
+ </t>
+ </section>
+ </section>
<section anchor="quic_comm" numbered="true" toc="default">
<name>QUIC communicator</name>
<t>
