commit c7503e54cb9190d3a3692e6fd6590ff13ed74e27
parent f755dc219c51341dd2acaa136666d4b633fa8b63
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 19 Jun 2024 09:24:26 +0200
cleanup some udp
Diffstat:
1 file changed, 101 insertions(+), 95 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -40,7 +40,14 @@
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-gnunet-communicators-00" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
+ category="info"
+ docName="draft-gnunet-communicators-00"
+ ipr="trust200902"
+ obsoletes="" updates=""
+ submissionType="independent"
+ xml:lang="en"
+ version="3">
<!-- xml2rfc v2v3 conversion 2.26.0 -->
<front>
<title abbrev="The GNUnet communicators">
@@ -71,6 +78,19 @@
<email>christian.grothoff@bfh.ch</email>
</address>
</author>
+ <author fullname="Pedram Fardzadeh" initials="P." surname="Fardzadeh">
+ <organization>Technischen Universität München</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>DE</country>
+ </postal>
+ <email>pedram.fardzadeh@tum.de</email>
+ </address>
+ </author>
+
<!-- Meta-data Declarations -->
<area>General</area>
@@ -99,7 +119,6 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
- FIXME
This document defines the normative wire format of resource
records, resolution processes, cryptographic routines and
security considerations for use by implementers.
@@ -125,7 +144,7 @@
<dl>
<dt>Communicator</dt>
<dd>
- FIXME This is a test
+ What is a communicator?
</dd>
</dl>
</section>
@@ -208,8 +227,6 @@
We use a hash-based key derivation function (HKDF) as defined in
<xref target="RFC5869" />, using SHA-256 <xref target="RFC6234"/> for the extraction
phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
- </t>
- <t>
We define the key derivation function (KDF) used to derive a uniform symmetric key
from the X25519 result "Z" and the ephemeral public key "A":
</t>
@@ -227,16 +244,6 @@ KDF(A,Z):
described in Section 5 of <xref target="BHKL13"/>.
</t>
<t>
-<<<<<<< HEAD
- Let G be the basepoint of Curve25519, EdToCurve() a function which converts Ed25519 points to their corresponding Curve25519
- points, Enc() Elligator's encoding function, Dec() Elligator's decoding function, REC_ID the receiver's peer identity (a 256-bit EdDSA public key),
- REC_SK the corresponding secret key, EPH_PUB the ephemeral Curve25519 public key and EPH_SK the corresponding secret key. Observe that:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-(REC_SK, REC_ID) := KeyGenEd25519()
-(EPH_SK, EPH_PUB) := KeyGenCurve25519()
-Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) = X25519(REC_SK, EPH_PUB)
-=======
Communicators use a modified version of the standard X25519 key exchange described in
section 6.1 of <xref target="RFC7748"/>.
We refer to the the ephemeral key pair as "a" and "A := a*G" where G is the generator of
@@ -246,6 +253,16 @@ Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) = X25519(REC_SK, EPH_PUB)
This use of a KEM and its safety has been investigated by <xref target="T21"/>.
</t>
<t>
+ 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,
+ preventing communication between peers.
+ The communicators <bcp14>MAY</bcp14> use the Elligator KEM defined in the following to produce random-looking
+ encapsulations (referred to as a "representative").
+ This leaves the attacker with the option to either do nothing or intercept all random-looking UDP packets,
+ thereby potentially disrupting a large part of today's internet communication.
+ </t>
+ <t>
Let G be the basepoint of Curve25519, EdToCurve() a function which converts Ed25519 points to their corresponding Curve25519 points,
Enc() Elligator's encoding function,
Dec() Elligator's decoding function, "X" the receiver's peer identity (a 256-bit EdDSA public key),
@@ -255,7 +272,6 @@ Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) = X25519(REC_SK, EPH_PUB)
(x, X) := KeyGenEd25519()
(a, A) := KeyGenX25519()
Z := X25519(a, EdToCurve(X)) = X25519(x, A)
->>>>>>> 75d0591 (update tcp)
]]></artwork>
<t>
We can then define the KEM:
@@ -266,19 +282,11 @@ EncapsElligator(X):
REPR := Enc(A, rand)
return REPR, MSK
-<<<<<<< HEAD
-Encaps(REC_ID):
- (EPH_SK, EPH_PUB) := KeyGenCurve25519()
- Z := X25519(EPH_SK, EdToCurve25519(REC_ID))
- MSK := KDF(EPH_PUB,Z)
- return EPH_PUB, MSK
-=======
Encaps(X):
(a, A) := KeyGenX25519()
Z := X25519(a, EdToCurve(X))
MSK := KDF(A,Z)
return A, MSK
->>>>>>> 75d0591 (update tcp)
]]></artwork>
<artwork anchor="decaps" name="" type="" align="left" alt=""><![CDATA[
DecapsElligator(x, REPR):
@@ -299,29 +307,35 @@ Decaps(x, A):
<section anchor="udp_comm" numbered="true" toc="default">
<name>UDP communicator</name>
<t>
- The UDP communicator implements an encryption layer that protects both the payload and the communicator's
- specific metadata (not to be confused with the UDP header). In particular, any message sent by the communicator
- is indistinguishable from random noise to an outside observer (FIXME: Not the case for BROADCAST messages).
+ The UDP communicator implements an encryption layer that protects both the payload and the communicator's
+ specific metadata (not to be confused with the UDP header). In particular, any message sent by the communicator
+ is indistinguishable from random payload to an outside observer, with the exception of broadcast messages.
</t>
<t>
- For any new connection to a target peer, the communicator attempts to establish a shared secret using an
- Elliptic-Curve Diffie-Hellman key exchange. The communicator initiating the connection creates an ephemeral
- key pair to encrypt the data for the target peer identity. Both the ephemeral public key and the encrypted
- data are sent to the receiving peer together with an authentication tag that authenticates the encrypted
- data. Independent of the payload, each message includes the sender's peer identity, a monotonic timestamp, and a
- signature over the session's meta data. Receivers should keep track of the monotonic timestamps for each peer
- ID to reject possible replay attacks. For each subsequent message the same procedure is conducted with a new
- ephemeral key pair.
- While the communicator always offers this type of message queue to a reachable peer, it is inefficient for
- high-volume data transfer because a new key exchange is conducted for every message.
+ For any new connection to a target peer, the communicator attempts to establish a shared secret using the
+ KEM defined in <xref target="elligator_kem"/>.
+ The communicator initiating the connection sends the resulting Elligator representative, the authentication tag
+ and the encrypted data to the receiving peer.
+ 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.
+ 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.
+ 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
+ to the receiving peer.
</t>
<t>
- If the target peer acknowledges the reception of a message, the employed key can be reused. Such acknowledgments
- can be sent either via a bi-directional UDP connection or a backchannel connection provided by TRANSPORT.
- This acknowledgment prompts the communicator to offer a new queue to TRANSPORT, which has a higher priority
- than the default queue but starts with limited capacity. The capacity increases whenever the communicator
- receives an acknowledgment for a transmission. This queue is suitable for high-volume data transfer, and TRANSPORT
- will prioritize it if available.
+ If the target peer is able to acknowledge the reception of a message, the employed key can be reused.
+ Such acknowledgments can be sent either via a bi-directional UDP connection or a backchannel connection provided
+ by TRANSPORT.
+ This acknowledgment prompts the communicator to offer a new queue to TRANSPORT, which has a higher priority
+ than the default queue but starts with limited capacity.
+ The capacity increases whenever the communicator receives an acknowledgment for a transmission.
+ This queue is suitable for high-volume data transfer, and TRANSPORT will prioritize it if available.
</t>
<t>
There are three distinct message types that are sent and received by UDP communicators: KX, BOX and BROADCAST.
@@ -332,20 +346,11 @@ Decaps(x, A):
<section anchor="Key_exchange" numbered="true" toc="default">
<name>Key exchange</name>
<t>
- Independent of the type of message queue, an X25519-based key exchange is at least initiated once by the sending peer. In cases
- where the receiving peer cannot acknowledge the reception of messages, a key exchange is performed for every message.
- 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 (KX) message as defined in
- <xref target="figure_udp_initialkx"/>.
- </t>
- <t>
- While the standard approach securely establishes a secret between both entities, an observer can easily detect a key exchange
- due to the transmission of an ephemeral public key from the sending peer to the receiving peer. In a censored environment,
- this could lead to packet interception, preventing communication between peers. The UDP communicator <bcp14>MUST</bcp14> encode
- the ephemeral public key into a random-looking byte stream (referred to as the "representative") before sending it. Since the
- GCM tag and the encrypted data in the key exchange message also appear random, the entire message is indistinguishable from a
- random byte stream. This leaves a censor with the option to either do nothing or intercept all random-looking UDP packets, thereby
- disrupting a disproportionate part of today's internet communication.
+ Independent of the type of message queue, a key exchange is initiated at least once by the sending peer.
+ In cases where the receiving peer cannot acknowledge the reception of messages, a key exchange is performed for every message.
+ Two key pairs are needed for the KEM: An ephemeral key pair generated as part of the encapsulation procedure
+ "EncapsElligator" and the peer identity of the receiving communciator.
+ The encapsulation is transfered 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[
@@ -372,12 +377,11 @@ Decaps(x, A):
<dl>
<dt>REPRESENTATIVE</dt>
<dd>
- A serialized Elligator encoded 256-bit Curve25519 public key. This encoded public key can be decoded and than used as part of an X25519-based
- key exchange to establish a shared secret.
+ The 256-bit serialized encapsulation result of the Elligator KEM.
</dd>
<dt>GCM TAG</dt>
<dd>
- A 128-bit GCM tag used to authenticate the ciphertext immediately following the header part of the KX message.
+ The 128-bit GCM tag used to authenticate the ciphertext immediately following the header part of the KX message.
</dd>
<dt>ENCRYPTED DATA</dt>
<dd>
@@ -387,16 +391,16 @@ Decaps(x, A):
</dl>
<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.
+ <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.
</t>
<figure anchor="figure_udp_confirmation" title="The binary representation of the KX Confirmation header">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
-| SENDER PEER ID |
+| SENDER PEER ID |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -442,11 +446,10 @@ Decaps(x, A):
</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 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"/>
</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.">
+ <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[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -512,45 +515,48 @@ Decaps(x, A):
</dd>
</dl>
<t>
- Upon receiving a KX message, the receiving peer decodes the representative into the original ephemeral public key and subsequently
- computes the shared secret. The UDP communicator utilizes the Elligator KEM described in <xref target="primitives"/>. 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 <xref target="udp_bc"/>.
+ Upon receiving a KX message, the receiving peer decapsulates the respresentative using the "DecapsElligator"
+ procedure defined in <xref target="elligator_kem"/> and receives a master secret key MSK.
+ 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
+ <xref target="udp_bc"/>.
</t>
<t>
- The resulting MSK is used to derive symmetric encryption key K and initialization vector IV using SetupCipher(MSQ,SEQ).
- Both the sending and the receiving peer <bcp14>SHOULD</bcp14> store the master shared secret MSK and attribute it to the corresponding peer.
- In case of an acknowledgment from the receiving peer, the established MSK can be reused by iterativly increasing the sequence number SEQ for SetupCipher(MSK, SEQ).
+ The MSK is then used together with a sequence number SEQ to derive symmetric encryption key K and initialization
+ vector IV using the "SetupCipher" procedure outlined below.
+ 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
+ the sequence number SEQ for SetupCipher(MSK, SEQ).
</t>
<t>
- Additional data might be inserted after the Confirmation header as part of the encrypted data of the KX message. Padding may be necessary
- due to the use of AES-GCM. 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 acknowledgment process and subsequent message exchange can be
- found in <xref target="udp_message_exchange"/>.
+ Additional data might be inserted after the confirmation header as part of the encrypted data of the KX message.
+ <!-- Wat? -->
+ Padding may be necessary due to the use of AES-GCM.
+ Once a KX message is received and validated, the peer <bcp14>SHOULD</bcp14> try to acknowledge the established
+ MSK to switch to a stable session.
+ The details about the acknowledgment 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 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>
- For SetupCipher, PRK_h is key material retrieved using an HKDF using the byte string
- seq as salt and k as initial keying material.
- key and initialization vector are the 256 + 96-bit HKDF expansion result.
- The expansion information input is the string "UDP-IV-KEY":
+ Once a shared secret MSK is established through the Elligator KEM, a symmetric key and
+ initialization vector are derived.
+ According to a key schedule from a 32-bit sequence number SEQ (in network byte order) and the MSK.
+ The initial value of the sequence number is 0.
</t>
<artwork anchor="setup_cipher" name="" type="" align="left" alt=""><![CDATA[
SetupCipher(MSK,SEQ):
- PRK_h := HKDF-Extract (SEQ, MSK)
- K,IV := HKDF-Expand (PRK_h, "gnunet-communicator-udp-key-iv", 32 + 12)
+ PRK := HKDF-Extract (SEQ, MSK)
+ K,IV := HKDF-Expand (PRK, "gnunet-communicator-udp-key-iv", 32 + 12)
return K,IV
]]></artwork>
<t>
- With SetupCipher, a 256-bit AES key as well as a 96-bit IV for use in AES-GCM
- are derived from the MSK and SEQ.
+ SetupCipher returns a 256-bit AES key "K" as well as a 96-bit "IV" for use in AES-GCM.
</t>
<t>
Each derived key is uniquely identified using a separately derived
@@ -558,13 +564,13 @@ SetupCipher(MSK,SEQ):
</t>
<artwork anchor="derive_kid" name="" type="" align="left" alt=""><![CDATA[
DeriveKID(MSK,SEQ):
- PRK_h := HKDF-Extract (SEQ, MSK)
- KID := HKDF-Expand (PRK_h, "gnunet-communicator-udp-kid", 256 / 8)
+ PRK := HKDF-Extract (SEQ, MSK)
+ KID := HKDF-Expand (PRK, "gnunet-communicator-udp-kid", 256 / 8)
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 senders side for each
+ successive encryption and on the receivers side for each decryption.
</t>
</section>
<section anchor="udp_message_exchange" numbered="true" toc="default">
