lsd0007

commit 578dc2e138f55633f874df854a79802d8f869e73
parent 0b25a60489d090e4abbcc7d0ba6370fca3121490
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date:   Fri, 14 Jun 2024 19:17:26 +0200

Updated parts of udp and tcp communicator

Diffstat:
M
draft-gnunet-communicators.xml
 | 
40
++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -245,7 +245,7 @@
         where the receiving peer cannot acknowledge the reception of packets, a key exchange is performed for every packet. The UDP
         communicator uses a modified version of the standard X25519 key exchange described in section 6.1 of <xref target="RFC7748"/>.
         The two key pair needed for such a key exchange is an ephemeral key pair generated by the initiating communiciator and the peer
-        identity of the receiving communciator. The ephemeral public key is transfered via a key exchange packet as defines in 
+        identity of the receiving communciator. The ephemeral public key is transfered via a key exchange packet as defined in 
         <xref target="figure_udp_initialkx"/>.
         </t>
         <t> 
@@ -396,7 +396,7 @@
          <dt>PURPOSE</dt>
          <dd>
            A 32-bit signature purpose flag in network byte order. The value of this
-           field <bcp14>MUST</bcp14> be XXXX.  It defines the context in which
+           field <bcp14>MUST</bcp14> be 33.  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
@@ -410,9 +410,9 @@
          <dd>
            A 256-bit EdDSA public key.
          </dd>
-         <dt>EPHEMERAL PEER ID</dt>
+         <dt>EPHEMERAL PUBLIC KEY</dt>
          <dd>
-           A 256-bit EdDSA public key.
+           A 256-bit Curve25519 public key. This public key is send in an encodeded format in the KX packet.
          </dd>
          <dt>MONOTONIC TIMESTAMP</dt>
          <dd>
@@ -423,10 +423,6 @@
            A 256-bit random value.
          </dd>
        </dl>
-       <t>
-         Once a KX message is received and validated, the peer <bcp14>SHOULD</bcp14>
-         try to acknowledge (ACK) the established shared secret.
-       </t>
         <t>
         Upon receiving a KX packet, the receiving peer decodes the representative into the original ephemeral public key and subsequently 
         computes the shared secret. The UDP communicator utilizes Elligator for the encoding and decoding of the ephemeral public key 
@@ -449,18 +445,18 @@ Decap(REPR) := (K,IV) = SetupCipher(X25519(REC_SK, Dec(REPR)), 0)
          be known to the sending peer. It is also important to mention that the ephemeral public key, which is depicted in the KEM as G.EPH_SK, is a point 
          on the whole Curve25519 and not restricted to its prime subgroup. This is due to the fact that Elligator's encoding function is defined on the 
          whole Curve25519. The exclusive usage of the prime subgroup would restrict the set of potential representatives, which in turn an outside observer 
-         can trivially recognize.
+         can trivially recognize. We also want emphasize, that the use of the peer identities for both Ed25519 signatures and X25519-based KEM has been proven 
+         to be safe. For further details, refer to the paper <xref target="T21"/>. 
          </t>
          <t>
-         The use of the peer identities for both Ed25519 signatures and X25519-based KEM has been proven to be safe. For further details, refer to the
-         paper <xref target="T21"/>. 
+         Once a KX message is received and validated, the peer <bcp14>SHOULD</bcp14> try to acknowledge the established shared secret to switch to the more
+         efficient queue. The details about the acknowledgement process and subsequent message exchange can be found in <xref target="udp_message_exchange"/>.
          </t>
      </section>
      <section anchor="udp_key_schedule" numbered="true" toc="default">
        <name>Key schedule</name>
        <t>
-         Once a shared secret MSK is established through the Diffie-Hellman KEM,
-         symmetric keys are derived according to a key schedule from a 32-bit
+         Once a shared secret MSK is established through within the Diffie-Hellman KEM, symmetric keys are derived according to a key schedule from a 32-bit
          sequence number seq (in network byte order).
        </t>
        <t>
@@ -486,7 +482,7 @@ SetupCipher(MSK,SEQ):
          Each derived key is uniquely identified using a separately derived
          256-bit key ID (KID) derived in a similar fashion:
        </t>
-       <artwork name="" type="" align="left" alt=""><![CDATA[
+       <artwork anchor="derive_kid" name="" type="" align="left" alt=""><![CDATA[
 DeriveKID(MSK,SEQ):
   PRK_h := HKDF-Extract (SEQ, MSK)
   KID := HKDF-Expand (PRK_h, "UDP-KID", 256 / 8)
@@ -500,6 +496,11 @@ DeriveKID(MSK,SEQ):
      <section anchor="udp_message_exchange" numbered="true" toc="default">
        <name>Message exchange</name>
        <t>
+       KX messages as presented in <xref target="Key_exchange"/> are sufficient for transferring arbitrary amounts of data. This way of 
+       communicating is slow, due to the establishment of a shared secret for each message using asymmetric cryptography. The UDP communicator 
+       offers a faster way of communication with the reuse of a shared secret. For this purpose, the receiver of a KX message needs to acknowledge 
+       the reception of the representative. The acknowledgement is sent via a UDP Box Message as defined in <xref target="figure_udp_box"/> which 
+       contains an ACK Header as its payload. The wire format of the ACK Header can be seen in <xref target="figure_udp_ack"/>. 
        (FIXME: documentation for message exchange is missing, specifically usage of UDP BOX and ACK Header)
        </t>
 <figure anchor="figure_udp_box" title="The binary representation of the UDP Box.">
@@ -528,7 +529,7 @@ DeriveKID(MSK,SEQ):
          <dt>KEY ID</dt>
          <dd>
            A 256-bit value containing the KID of the symmetric key to
-           use for decryption as derived using DeriveKID.
+           use for decryption as derived using DeriveKID as described in <xref target="derive_kid"/>.
          </dd>
          <dt>GCM TAG</dt>
          <dd>
@@ -612,9 +613,8 @@ DeriveKID(MSK,SEQ):
        TCP communicators always establish an encrypted and bi-directional communication channel. For 
        each direction of communication, a dedicated shared secret is used to both encrypt and 
        authenticate messages. These shared secrets are exchanged during the initial handshake. After a 
-       certain amount of data has been transmitted, re-keying occurs to renew the key material 
-       (FIXME: Currently, hard-coded to 4 GB!). Note that the re-keying process is triggered individually 
-       for each communication direction.
+       certain amount of data has been transmitted, re-keying occurs to renew the key material. 
+       Note that the re-keying process is triggered individually for each communication direction.
      </t>
      <t>
        To achieve a zero-plaintext design, we <bcp14>MUST</bcp14> use the mac-then-encrypt approach to 
@@ -1053,8 +1053,8 @@ SetupCipher(MSK):
      <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. 
+     details please refer to <xref target="tcp_KEM"/>. Note that th reception of the TCP Rekey packet is not acknowledged by the receiver, so 
+     the sender might send new payload encrypted by the new key right after sending the packet. 
      </t>
      <figure anchor="figure_tcp_rekey" title="The binary representation of the TCP Rekey packet.">
          <artwork name="" type="" align="left" alt=""><![CDATA[