commit 8403a27d942f5179b77b29c4c78e869084169a13
parent 2d534a9728b1f7058db1bd12bbc6d1c6a466a19b
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Mon, 12 Aug 2024 13:27:33 +0200
spelling error
Diffstat:
1 file changed, 63 insertions(+), 63 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -126,7 +126,7 @@
</t>
<t>
This specification was developed outside the IETF and does not have
- IETF consensus. It is published here to guide implementers of GNS
+ IETF consensus. It is published here to guide GNS implementers
and to ensure interoperability among implementations.
</t>
<section numbered="true" toc="default">
@@ -158,7 +158,7 @@
<dl>
<dt>(skXed, pkXed)</dt>
<dd>
- Akey pair used in role X, where X is one of S as sender or R as recipient, respectively;
+ A key pair is used in role X, where X is one of S as sender or R as recipient, respectively;
skXed is the Ed25519 private key and pkXed is the Ed25519 public key as defined in
<xref target="RFC8032"/>.
</dd>
@@ -167,10 +167,10 @@
<name>Overview</name>
<t>
Each communicator must specify its (global) communication characteristics,
- which for now only say whether the communication is reliable (e.g. TCP, HTTPS)
- or unreliable (e.g. UDP, WLAN).
+ which for now only say whether the communication is reliable (e.g., TCP, HTTPS)
+ or unreliable (e.g., UDP, WLAN).
Each communicator must specify a unique address prex, or NULL if the
- communicator cannot establish outgoing connections (for example because
+ communicator cannot establish outgoing connections (for example, because
it is only acting as a TCP server).
A communicator must tell TRANSPORT which addresses it is reachable under.
Addresses may be added or removed at any time.
@@ -203,13 +203,13 @@
</t>
<t>
The communicator API also provides for flow control.
- First, communicators exhibit back-pressure on TRANSPORT:
+ First, communicators exhibit backpressure on TRANSPORT:
the number of messages TRANSPORT may add to a queue for transmission will
be limited.
- So by not draining the transmission queue, back-pressure is provided to
+ So, by not draining the transmission queue, backpressure is provided to
TRANSPORT.
In the other direction, communicators may allow TRANSPORT to give
- back-pressure towards the communicator by providing a non-NULL
+ backpressure towards the communicator by providing a non-NULL
GNUNET_TRANSPORT_MessageCompletedCallback argument to the
GNUNET_TRANSPORT_communicator_receive function.
In this case, TRANSPORT will only invoke this function once it has
@@ -218,7 +218,7 @@
this backpressure.
Note that communicators do not have to provide a
GNUNET_TRANSPORT_MessageCompletedCallback;
- for example, UDP cannot support back-pressure due to the nature of the
+ for example, UDP cannot support backpressure due to the nature of the
UDP protocol.
In this case, TRANSPORT will implement its own TRANSPORT-to-TRANSPORT
flow control to reduce the sender’s data rate to acceptable levels.
@@ -229,8 +229,8 @@
Similarly, communicators can ask TRANSPORT to try to send a backchannel
message to other communicators of other peers.
The semantics of the backchannel message are up to the communicators
- which use them.
- TRANSPORT may fail transmitting backchannel messages, and TRANSPORT will
+ who use them.
+ TRANSPORT may fail to transmit backchannel messages, and TRANSPORT will
not attempt to retransmit them.
</t>
</section>
@@ -243,7 +243,7 @@
the ephemeral public keys.
While standard Diffie-Hellman-based KEMs securely establish a secret between
two parties, an observer can easily identify the encapsulation as a public key.
- In the presence of an active attacker this could lead to packet dropping based on this information,
+ In the presence of an active attacker, this could lead to packet dropping based on this information,
preventing communication between peers.
The UDP and TCP communicators use the Elligator KEM defined in
<xref target="LSD0011"/>.
@@ -287,13 +287,13 @@
Since the GCM authentication tag and the encrypted data in the key exchange message also appear random,
the entire message is computationally indistinguishable from a random byte stream.
Independent of the payload, each message includes the sender's peer identity, a monotonic timestamp, and a
- signature over the session meta data.
+ signature over the session metadata.
Receivers <bcp14>MUST</bcp14> keep track of the monotonic timestamps of key exchanges with each peer
to prevent replay attacks.
- For each subsequent message the same procedure is conducted with a new encapsulation.
+ For each subsequent message the same procedure is used with a new encapsulation.
While the communicator may always fall back to this type of encryption, it is inefficient for
high-volume data transfer because a new key exchange is required for every message.
- However, sometimes we may have no other choice, for example if there is only bi-directional connectivity
+ However, sometimes we may have no other choice, for example, if there is only bi-directional connectivity
to the receiving peer.
</t>
<t>
@@ -323,7 +323,7 @@
In order to use it compliantly with a X25519-based DHKEM as defined in <xref target="LSD0011"/> and <xref target="RFC9180"/>, the
curve point must first be converted from Edwards into its birationally equivalent Montgomery form
<tt>pkR</tt>.
- The encapsulation <tt>enc</tt> is transfered via a key exchange (KX) message as defined in <xref target="figure_udp_initialkx"/>.
+ The encapsulation <tt>enc</tt> is transferred via a key exchange (KX) message, as defined in <xref target="figure_udp_initialkx"/>.
</t>
<figure anchor="figure_udp_initialkx" title="The binary representation of the KX message.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -354,7 +354,7 @@
</dd>
<dt>GCM TAG</dt>
<dd>
- The 128-bit GCM tag used to authenticate the ciphertext immediately following the header part of the KX message.
+ The 128-bit GCM tag is used to authenticate the ciphertext immediately following the header part of the KX message.
</dd>
<dt>ENCRYPTED DATA</dt>
<dd>
@@ -365,8 +365,8 @@
<t>
In order to prevent replay attacks for KX messages, the plaintext resulting from decryption of the encrypted data
<bcp14>MUST</bcp14> must start with a session-specific Confirmation header as defined in <xref target="figure_udp_confirmation"/>.
- It includes the sender's peer identity and a monotonic timestamp which the receiving peer <bcp14>MUST</bcp14>
- keep track for each peer identity to reject possible replay attacks.
+ It includes the sender's peer identity and a monotonic timestamp, which the receiving peer <bcp14>MUST</bcp14>
+ keep track of each peer identity to reject possible replay attacks.
</t>
<figure anchor="figure_udp_confirmation" title="The binary representation of the KX Confirmation header">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -407,11 +407,11 @@
<dt>SIGNATURE</dt>
<dd>
The EdDSA signature is computed with the peer private key
- over the session metadata as detailed in <xref target="figure_udp_handshake_sig"/>.
+ over the session metadata, as detailed in <xref target="figure_udp_handshake_sig"/>.
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in microseconds and in network byte order.
</dd>
<dt>PAYLOAD</dt>
<dd>
@@ -419,8 +419,8 @@
</dd>
</dl>
<t>
- The confirmation header also includes a signature over the session's meta data, which is signed with the corresponding private key of
- the sender peer identity. The data format over which the signature is computed is defined in <xref target="figure_udp_handshake_sig"/>
+ The confirmation header also includes a signature over the session's metadata, which is signed with the corresponding private key of
+ the sender's peer identity. The data format over which the signature is computed is defined in <xref target="figure_udp_handshake_sig"/>
</t>
<figure anchor="figure_udp_handshake_sig" title="The wire format of the data structure over which the signature of the UDP Confirmation header is computed.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -465,7 +465,7 @@
A 32-bit signature purpose flag in network byte order. The value of this
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.
+ 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>
@@ -483,7 +483,7 @@
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in microseconds and in network byte order.
</dd>
</dl>
<t>
@@ -493,7 +493,7 @@
This <tt>Decap(skR, enc)</tt> procedure is defined in <xref target="LSD0011"/>.
Note that the exchange of the receiver peer identity is not within the scope of the UDP communicator's key
exchange and is already assumed to be known to the sending peer.
- One way to exchange peer identites is through the means of UDP BROADCAST messages as described in
+ One way to exchange peer identities is through the UDP BROADCAST messages as described in
<xref target="udp_bc"/>.
</t>
<t>
@@ -502,7 +502,7 @@
Both the sending and the receiving peer <bcp14>SHOULD</bcp14> store the master shared secret MSK and attribute
it to the corresponding peer.
<!-- FIXME SEQ is increased by ACKs! -->
- In case of an acknowledgment from the receiving peer, the established MSK can be reused by iterativly increasing
+ In case of an acknowledgment from the receiving peer, the established MSK can be reused by iteratively increasing
the sequence number SEQ for SetupCipher(MSK, SEQ).
</t>
<t>
@@ -542,19 +542,19 @@ DeriveKID(MSK,SEQ):
return KID
]]></artwork>
<t>
- The sequence number SEQ for any shared secret is initially 0 and incremented on the senders side for each
- successive encryption and on the receivers side for each decryption.
+ The sequence number SEQ for any shared secret is initially 0 and incremented on the sender side for each
+ successive encryption and on the receiver side for each decryption.
</t>
</section>
<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 message <bcp14>SHOULD</bcp14>
+ 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 communicating by reusing a shared secret. For this purpose, the receiver of a message <bcp14>SHOULD</bcp14>
acknowledge the reception to signal the sender that the same shared secret can be reused. The sender can then use the acknowledged shared
secret and increment the utilized sequence number for each subsequent message to derive new symmetric key material. These messages are
- send as BOX messages, which incorporate a KID as defined in <xref target="derive_kid"/> to identify both the master shared secret and
+ sent as BOX messages, which incorporate a KID as defined in <xref target="derive_kid"/> to identify both the master shared secret and
sequence number. The wire format of a BOX message is depicted in <xref target="figure_udp_box"/>.
</t>
<figure anchor="figure_udp_box" title="The binary representation of the UDP Box message.">
@@ -639,7 +639,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>SEQ ACK</dt>
<dd>
- Sequence acknowledgment limit. Specifies current maximum sequence number supported by receiver.
+ Sequence acknowledgment limit. Specifies the current maximum sequence number supported by the receiver.
</dd>
<dt>MSK HASH</dt>
<dd>
@@ -661,7 +661,7 @@ DeriveKID(MSK,SEQ):
<section anchor="udp_rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>
- The amount of data which can be encrypted with a shared secret <bcp14>MUST</bcp14> be limited. Before
+ The amount of data that can be encrypted with a shared secret <bcp14>MUST</bcp14> be limited. Before
the capacity of a shared secret is used up, the sender initiates rekeying by sending a new ephemeral public key
for a key exchange. As multiple shared secrets can be used simultaneously, rekeying doesn't necessarily delete the old shared secret if its
capacity is not yet reached. The ephemeral public key is sent encrypted in a Rekey header as part of the payload of BOX message. Because the
@@ -738,7 +738,7 @@ DeriveKID(MSK,SEQ):
<dt>SIGNATURE</dt>
<dd>
The EdDSA signature is computed with the announced peer private key
- over the peer identity and address hash as depicted in <xref target="figure_udp_broadcast_sig"/>.
+ over the peer identity and address hash, as depicted in <xref target="figure_udp_broadcast_sig"/>.
</dd>
</dl>
<figure anchor="figure_udp_broadcast_sig" title="The wire format of the data structure over which the signature of the UDP BROADCAST message is computed.">
@@ -770,7 +770,7 @@ DeriveKID(MSK,SEQ):
A 32-bit signature purpose flag in network byte order. The value of this
field <bcp14>MUST</bcp14> be 34. 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.
+ 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>
@@ -791,8 +791,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.
- Note that the re-keying process is triggered individually for each communication direction.
+ certain amount of data has been transmitted, rekeying occurs to renew the key material.
+ Note that the rekeying 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
@@ -811,11 +811,11 @@ DeriveKID(MSK,SEQ):
defined in <xref target="elligator_dhkem"/>.
</t>
<t>
- The encapsulation <bcp14>MUST</bcp14> be directly followed by an encrypted TCP handshake message as shown in
+ The encapsulation <bcp14>MUST</bcp14> be directly followed by an encrypted TCP handshake message, as shown in
<xref target="figure_tcp_handshake"/>.
In addition to the peer identity of the sender and a timestamp, it contains a nonce as a challenge for the
receiving TCP communicator.
- All data is authenticated with signature.
+ All data is authenticated with a signature.
</t>
<figure anchor="figure_tcp_handshake" title="The binary representation of the TCP handshake message.">
<artwork name="" type="" align="left" alt=""><