commit 136874cea780c7df2aa1800daca0d4daf6f8116c
parent aeebb541ff8cee56abfbc3b655612d623f465ca4
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 16 Apr 2025 13:38:16 +0200
typos
Diffstat:
1 file changed, 23 insertions(+), 27 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -211,7 +211,7 @@ ss_R | |
| c_e |
| r_R |
| {svcinfo_R,c_I}RHTS |
- | {rfinished}RHTS |
+ | {finished_R}RHTS |
| *[Application Payload]RATS |
|<----------------------------------------------+
r_R | |
@@ -220,7 +220,7 @@ c_e | |
ss_I | |
ss_e | |
| InitiatorDone: |
- | {ifinished}IHTS |
+ | {finished_I}IHTS |
| *[Application Payload]IATS |
+---------------------------------------------->|
| |
@@ -234,14 +234,14 @@ ss_e | |
]]></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 finished<sub>I</sub> (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 finished<sub>I</sub>.
+ finished<sub>I</sub> 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 finished<sub>I</sub> (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>
@@ -275,8 +275,8 @@ ss_e | |
<ol>
<li>r<sub>R</sub> <- RandomUInt64(). Receiver nonce.</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>Create finished<sub>R</sub> as per <xref target="cake_hs_proto"/>.</li>
+ <li>Encrypt finished<sub>R</sub> with RHTS.</li>
<li>Optionally, R may now already send application data encrypted with RATS.</li>
</ol>
<t>
@@ -285,11 +285,11 @@ ss_e | |
<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 svcinfo_R, 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 finished<sub>R</sub>.</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 finished<sub>R</sub> as per <xref target="cake_hs_proto"/> and check against decrypted payload.</li>
+ <li>Create finished<sub>I</sub> as per <xref target="cake_hs_proto"/>.</li>
+ <li>Send finished<sub>I</sub> message encrypted with the key derived from IHTS to R</li>
</ol>
<t>
At this point we have a secure channel.
@@ -303,7 +303,7 @@ ss_e | |
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: finished<sub>I</sub>.
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
@@ -340,10 +340,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({finished_I})))
| = IATS_0
|
- +-----> HKDF-Expand(., "r ap traffic", H(T({rfinished})))
+ +-----> HKDF-Expand(., "r ap traffic", H(T({finished_R})))
= RATS_0
]]></artwork>
</figure>
@@ -421,21 +421,17 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
<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 finished<sub>I</sub>
+ or finished<sub>R</sub> 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>finished<sub>I</sub> <- HMAC(fk<sub>I</sub>, H(T({finished<sub>R</sub>})))</li>
</ol>
<ol>
<li>fk<sub>R</sub> <- HKDF-Expand(MS, "r finished", NULL)</li>
- <li>rfinished <- HMAC(fk<sub>R</sub>, H(T({svcinfo_R,c_I}))</li>
+ <li>finished<sub>R</sub> <- 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.
- </t>
</section>
<section anchor="cake_hs_msg_fmt" numbered="true" toc="default">
<name>CAKE Message Format</name>
@@ -528,20 +524,20 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
+-----+-----+-----+-----+-----+-----+-----+-----+
| r_R |
+-----+-----+-----+-----+-----+-----+-----+-----+
- / {svcinfo_R,c_I}{rfinished} /
+ / {svcinfo_R,c_I}{finished_R} /
]]></artwork>
</figure>
<t>
The protected fields after the nonce are encrypted using a key derived from AHTS.
- The rfinished is encrypted individually.
+ The finished<sub>R</sub> is encrypted individually.
This is because the transcript of the ReceiverHello to generate the
- rfinished must end before it.
+ finished<sub>R</sub> 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 finished<sub>I</sub> field
encrypted with a key derived from the IHTS.
The message type <bcp14>MUST</bcp14> be CORE_INITIATOR_DONE.
</t>
