commit ddd1225fb1708a0ef1edb2515b184d291f0c7983
parent 2422b8b2e026165f33eb4f06d2e7dad0f95a5bdd
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 16 Apr 2025 10:42:52 +0200
harmonize naming
Diffstat:
1 file changed, 54 insertions(+), 51 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -184,41 +184,43 @@ else
<artwork name="" type="" align="left" alt=""><![CDATA[
Initiator Receiver
sk_I | | sk_R
-pk_R | |
sk_e | |
-ES,ETS | |
+pk_R | |
+c_R | |
+ss_e | |
+ss_R | |
| |
| InitiatorHello: |
| pk_e |
| c_R |
| r_I |
| H(pk_R) |
- | {pk_I,ServicesInfo}ETS |
+ | {pk_I,svcinfo_I}ETS |
+---------------------------------------------->|
+ | | r_I
| | pk_I
- | | ES,ETS
- | | dES
- | | (d)HS
- | | MS
- | | [I,R]HTS
- | | RATS
+ | | c_R
+ | | c_I
+ | | c_e
+ | | ss_R
+ | | ss_I
+ | | ss_e
| ReceiverHello: |
| c_e |
| r_R |
- | {ServicesInfo,c_I}RHTS |
- | {RFinished}RHTS |
+ | {svcinfo_R,c_I}RHTS |
+ | {rfinished}RHTS |
| *[Application Payload]RATS |
|<----------------------------------------------+
-dES | |
-(d)HS | |
-MS | |
-[I,R]HTS | |
-[I,R]ATS | |
+r_R | |
+c_e | |
+ss_I | |
+ss_e | |
| InitiatorDone: |
- | {IFinished}IHTS |
+ | {ifinished}IHTS |
| *[Application Payload]IATS |
+---------------------------------------------->|
- | | IATS
+ | |
| |
| |
| |
@@ -229,19 +231,19 @@ MS | |
]]></artwork>
</figure>
<t>
- Notice how we do not need any acknowledgement messages until after IFinished (after 1.5 RTT).
+ Notice how we do not need any acknowledgement messages until after ifinished (after 1.5 RTT).
The InitiatorHello message is a single flight that is implicitly ack'ed with ReceiverHello.
- ReceiverHello is a single flight that is implicitly ack'ed with IFinished.
- IFinished requires an explicit ack; at this time R and I have already established a secure channel
+ ReceiverHello is a single flight that is implicitly ack'ed with ifinished.
+ ifinished requires an explicit ack; at this time R and I have already established a secure channel
and R can use an EncryptedMessage to send the ack.
The reason why this works is because CAKE groups the messages in row 3 of Table 1 in <xref target="RFC9147" section="5.7"/> into a single message (ReceiverHello).
Hence the only message that is sent without any expected response (and consequently requiring an explicit
- ACK) is IFinished (and KeyUpdate).
+ ACK) is ifinished (and KeyUpdate).
N<sub>I</sub> is a nonce generated by the initiator.
N<sub>R</sub> is a nonce generated by the receiver.
</t>
<t>
- The Initiator creates the InitiatorHello message which includes the encrypted tuple (pk<sub>I</sub>,ServicesInfo).
+ The Initiator creates the InitiatorHello message which includes the encrypted tuple (pk<sub>I</sub>,svcinfo_I).
The fields are encrypted using a key derived from the ETS according to <xref target="figure_swimlane"/>
and <xref target="figure_key_schedule"/>.
The so-called Receiver KEM Challenge c<sub>R</sub> and the nonce r<sub>I</sub> are computed as:
@@ -258,7 +260,7 @@ MS | |
<li>Verify that H(pk_R) matches R's pk_R.</li>
<li>(ss<sub>R</sub>,c<sub>R</sub>) <- Decaps(sk<sub>R</sub>, c<sub>R</sub>). Response to Receiver KEM Challenge.</li>
<li>(ss<sub>e</sub>,c<sub>e</sub>) <- Encaps(pk<sub>e</sub>). Ephemeral shared secret.</li>
- <li>Generate ETS from <xref target="key_schedule"/> and decrypt pk<sub>I</sub>. pk<sub>I</sub> and ServicesInfo may be processed now.</li>
+ <li>Generate ETS from <xref target="key_schedule"/> and decrypt pk<sub>I</sub>. pk<sub>I</sub> and svcinfo_I may be processed now.</li>
<li>(ss<sub>I</sub>,c<sub>I</sub>) <- Encaps(pk<sub>I</sub>). Initiator KEM Challenge.</li>
<li>Generate RHTS and RATS from <xref target="key_schedule"/>.</li>
</ol>
@@ -269,9 +271,9 @@ MS | |
</t>
<ol>
<li>r<sub>R</sub> <- RandomUInt64(). Receiver nonce.</li>
- <li>Encrypt ServicesInfo and c<sub>I</sub> (Initiator KEM Challenge) using RHTS.</li>
- <li>Create RFinished as per <xref target="cake_hs_proto"/>.</li>
- <li>Encrypt RFinished with RHTS.</li>
+ <li>Encrypt svcinfo_R and c<sub>I</sub> (Initiator KEM Challenge) using RHTS.</li>
+ <li>Create rfinished as per <xref target="cake_hs_proto"/>.</li>
+ <li>Encrypt rfinished with RHTS.</li>
<li>Optionally, R may now already send application data encrypted with RATS.</li>
</ol>
<t>
@@ -280,11 +282,11 @@ MS | |
<ol>
<li>Verify that the message type is CORE_RECEIVER_HELLO. See Message Header</li>
<li>ss<sub>e</sub> <- Decaps(sk<sub>e</sub>,c<sub>e</sub>). Ephemeral shared secret.</li>
- <li>Generate IHTS and RHTS from <xref target="key_schedule"/> and decrypt ServicesInfo, c<sub>I</sub> and RFinished.</li>
+ <li>Generate IHTS and RHTS from <xref target="key_schedule"/> and decrypt svcinfo_R, c<sub>I</sub> and rfinished.</li>
<li>ss<sub>I</sub> <- Decaps(sk<sub>I</sub>,c<sub>I</sub>). Response to KEM Challenge</li>
- <li>Create RFinished as per <xref target="cake_hs_proto"/> and check against decrypted payload.</li>
- <li>Create IFinished as per <xref target="cake_hs_proto"/>.</li>
- <li>Send IFinished message encrypted with the key derived from IHTS to R</li>
+ <li>Create rfinished as per <xref target="cake_hs_proto"/> and check against decrypted payload.</li>
+ <li>Create ifinished as per <xref target="cake_hs_proto"/>.</li>
+ <li>Send ifinished message encrypted with the key derived from IHTS to R</li>
</ol>
<t>
At this point we have a secure channel.
@@ -298,7 +300,7 @@ MS | |
But we only have a single message that contains a payload encrypted with a key
derived from RHTS: ReceiverHello.
We also only have a single message that contains a payload encrypted with a key
- derived from IHTS: IFinished.
+ derived from IHTS: ifinished.
Consequently, we do not need any signalling of Epochs until we encrypt data using
*ATS secrets.
The optional application data that may already be sent by the receiver after its first
@@ -335,10 +337,10 @@ HKDF-Expand(., "derived", "") = derived Handshake Secret (dHS)
v
HKDF-Extract(ss_I,.) = Master Secret (MS)
|
- +-----> HKDF-Expand(., "i ap traffic", H(T({IFinished})))
+ +-----> HKDF-Expand(., "i ap traffic", H(T({ifinished})))
| = IATS_0
|
- +-----> HKDF-Expand(., "r ap traffic", H(T({RFinished})))
+ +-----> HKDF-Expand(., "r ap traffic", H(T({rfinished})))
= RATS_0
]]></artwork>
</figure>
@@ -405,31 +407,31 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
</t>
</section>
<section anchor="svcinfo" numbered="true" toc="default">
- <name>ServicesInfo Field</name>
+ <name>Services Info Field</name>
<t>
- The ServicesInfo is a string consisting of key-value pairs separated by
+ The svcinfo field is a string consisting of key-value pairs separated by
a separator indicating supported services and their versions.
E.g. "dht:1.1;cadet:0.4".
- The ServicesInfo is zero terminated.
+ The field is zero terminated.
</t>
</section>
<section anchor="finished_field" numbered="true" toc="default">
<name>Finished Field</name>
<t>
- The HandshakeFinished field contains either IFinished
- or RFinished value:
+ The HandshakeFinished field contains either ifinished
+ or rfinished value:
</t>
<ol>
<li>fk<sub>I</sub> <- HKDF-Expand(MS, "i finished", NULL)</li>
- <li>IFinished <- HMAC(fk<sub>I</sub>, H(T({RFinished})))</li>
+ <li>ifinished <- HMAC(fk<sub>I</sub>, H(T({rfinished})))</li>
</ol>
<ol>
<li>fk<sub>R</sub> <- HKDF-Expand(MS, "r finished", NULL)</li>
- <li>RFinished <- HMAC(fk<sub>R</sub>, H(T({ServicesInfo,c_I}))</li>
+ <li>rfinished <- HMAC(fk<sub>R</sub>, H(T({svcinfo_R,c_I}))</li>
</ol>
<t>
- Observe how the RFinished transcript used as input into the HMAC cannot include
- the RFinished of the ReceiverHello message itself.
+ Observe how the rfinished transcript used as input into the HMAC cannot include
+ the rfinished of the ReceiverHello message itself.
</t>
</section>
<section anchor="cake_hs_msg_fmt" numbered="true" toc="default">
@@ -492,7 +494,7 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
+-----+-----+-----+-----+-----+-----+-----+-----+
| r_I |
+-----+-----+-----+-----+-----+-----+-----+-----+
- / {pk_I,ServicesInfo} /
+ / {pk_I,svcinfo_I} /
]]></artwork>
</figure>
<t>
@@ -523,20 +525,20 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
+-----+-----+-----+-----+-----+-----+-----+-----+
| r_R |
+-----+-----+-----+-----+-----+-----+-----+-----+
- / {ServicesInfo,c_I}{RFinished} /
+ / {svcinfo_R,c_I}{rfinished} /
]]></artwork>
</figure>
<t>
The protected fields after the nonce are encrypted using a key derived from AHTS.
- The RFinished is encrypted individually.
+ The rfinished is encrypted individually.
This is because the transcript of the ReceiverHello to generate the
- RFinished must end before it.
+ rfinished must end before it.
</t>
</section>
<section anchor="handshake_finished" numbered="true" toc="default">
<name>InitiatorDone Message</name>
<t>
- The InitiatorDone message contains the IFinished field
+ The InitiatorDone message contains the ifinished field
encrypted with a key derived from the IHTS.
The message type <bcp14>MUST</bcp14> be CORE_INITIATOR_DONE.
</t>
@@ -593,8 +595,9 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
according to the key schedule in <xref target="key_schedule"/>.
If any bit in the UpdateRequested field is set, this means that the receiver
of the KeyUpdate <bcp14>MUST</bcp14> send its own KeyUpdate message.
- Any bytes following the UpdateRequested field are updated ServicesInfo (<xref target="svcinfo"/>).
- ServicesInfo updates are optional.
+ Any bytes following the UpdateRequested field are updated services info
+ svcinfo (<xref target="svcinfo"/>).
+ Services info updates are optional.
<!-- TODO: Incremental or full ServicesInfo -->
</t>
<figure anchor="figure_keyupdate_msg" title="The Wire Format of the EncryptedMessage header.">
@@ -603,7 +606,7 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
+-----+-----+-----+-----+
| UpdateRequested |
+-----+-----+-----+-----+
-| ServicesInfo /
+| svcinfo /
/ /
]]></artwork>
</figure>
