commit 610fcafeadff7ca6d73e6049c82f8714e41a1e64
parent 87be333e0cbc4dde3810d3bd8cd0a5cd00ef5453
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 15 Apr 2025 22:29:15 +0200
formatting
Diffstat:
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -129,7 +129,7 @@
<dt>ES:</dt> <dd>Early Secret Key</dd>
<dt>IHTS:</dt> <dd>Initiator Handshake Secret Key</dd>
<dt>RHTS:</dt> <dd>Receiver Handshake Secret Key</dd>
- <dt>TH(M):</dt> <dd>means the transcript hash of a concatenation of received/sent messages starting from the InitiatorHello until and including M. Note that the transcript refers to what is seen on the wire (i.e. potentially encryption). The hash function used is TBD (Blake2b?)</dd>
+ <dt>T(M):</dt> <dd>means the transcript as a concatenation of received/sent messages starting from the InitiatorHello until and including M. Note that the transcript refers to what is seen on the wire (i.e. potentially encryption).</dd>
<dt>'{}K'</dt> <dd>indicates encryption with a handshake traffic key K and <xref target="RFC8439"/>, the ChaCha20-Poly1305 Authenticated Encryption with Associated Data (AEAD) construction.</dd>
<dt>'[]K'</dt> <dd>indicates encryption with an application traffic key K and <xref target="RFC8439"/>, the ChaCha20-Poly1305 Authenticated Encryption with Associated Data (AEAD) construction.</dd>
</dl>
@@ -205,7 +205,7 @@ ES,ETS | |
| c_e |
| r_R |
| {ServicesInfo,c_I}RHTS |
- | {ReceiverFinished}RHTS |
+ | {RFinished}RHTS |
| *[Application Payload]RATS |
|<----------------------------------------------+
dES | |
@@ -214,7 +214,7 @@ MS | |
[I,R]HTS | |
[I,R]ATS | |
| InitiatorDone: |
- | {InitiatorFinished}IHTS |
+ | {IFinished}IHTS |
| *[Application Payload]IATS |
+---------------------------------------------->|
| | IATS
@@ -228,14 +228,14 @@ MS | |
]]></artwork>
</figure>
<t>
- Notice how we do not need any acknowledgement messages until after InitiatorFinished (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 InitiatorFinished.
- InitiatorFinished 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 InitiatorFinished (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>
@@ -268,8 +268,8 @@ MS | |
<ol>
<li>r<sub>R</sub> <- RandomUInt64()</li>
<li>Encrypt ServicesInfo and c<sub>I</sub> the key derived from RHTS.</li>
- <li>Create ReceiverFinished as per <xref target="cake_hs_proto"/>.</li>
- <li>Encrypt ReceiverFinished with 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>
@@ -278,11 +278,11 @@ MS | |
<ol>
<li>Verify that the message type is CORE_RECEIVER_HELLO</li>
<li>ss<sub>e</sub> <- Decaps(sk<sub>e</sub>,c<sub>e</sub>)</li>
- <li>Generate IHTS and RHTS from <xref target="key_schedule"/> and decrypt ServicesInfo, c<sub>I</sub> and ReceiverFinished.</li>
+ <li>Generate IHTS and RHTS from <xref target="key_schedule"/> and decrypt ServicesInfo, c<sub>I</sub> and RFinished.</li>
<li>ss<sub>I</sub> <- Decaps(sk<sub>I</sub>,c<sub>I</sub>).</li>
- <li>Create ReceiverFinished as per <xref target="cake_hs_proto"/> and check against decrypted payload.</li>
- <li>Create InitiatorFinished as per <xref target="cake_hs_proto"/>.</li>
- <li>Send InitiatorFinished 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.
@@ -296,7 +296,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: InitiatorFinished.
+ 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
@@ -311,38 +311,38 @@ MS | |
</t>
<figure anchor="figure_key_schedule" title="The Key Schedule.">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0
- |
- v
-ss_R -> HKDF-Extract = Early Secret (ES)
- |
- +-----> HKDF-Expand(., "early data", TH(H(pk_R)))
- | = Early Transport Secret (ETS)
- |
- v
- HKDF-Expand(., "derived", "") = derived Early Secret (dES)
- |
- v
-ss_e -> HKDF-Extract = Handshake Secret (HS)
- |
- +-----> HKDF-Expand(., "i hs traffic", TH(r_R))
- | = IHTS
- |
- +-----> HKDF-Expand(., "r hs traffic", TH(r_R))
- | = RHTS
- v
- HKDF-Expand(., "derived", "") = derived Handshake Secret (dHS)
- |
- v
-ss_I -> HKDF-Extract = Master Secret (MS)
- |
- +-----> HKDF-Expand(., "i ap traffic", TH({InitiatorFinished}))
- | = IATS_0
- |
- +-----> HKDF-Expand(., "r ap traffic", TH({ReceiverFinished}))
- = RATS_0
+HKDF-Extract(ss_R,0) = Early Secret (ES)
+ |
+ +-----> HKDF-Expand(., "early data", H(T(H(pk_R))))
+ | = Early Transport Secret (ETS)
+ |
+ v
+HKDF-Expand(., "derived", "") = derived Early Secret (dES)
+ |
+ v
+HKDF-Extract(ss_e,.) = Handshake Secret (HS)
+ |
+ +-----> HKDF-Expand(., "i hs traffic", H(T(r_R)))
+ | = IHTS
+ |
+ +-----> HKDF-Expand(., "r hs traffic", H(T(r_R)))
+ | = RHTS
+ v
+HKDF-Expand(., "derived", "") = derived Handshake Secret (dHS)
+ |
+ v
+HKDF-Extract(ss_I,.) = Master Secret (MS)
+ |
+ +-----> HKDF-Expand(., "i ap traffic", H(T({IFinished})))
+ | = IATS_0
+ |
+ +-----> HKDF-Expand(., "r ap traffic", H(T({RFinished})))
+ = RATS_0
]]></artwork>
- </figure>
+ </figure>
+ <t>
+ "." refers to the input variable from the
+ </t>
<t>
In general the transcript hashes are part of the HKDF-Expand calls.
The transcript hash is defined as the hash over the message parts sent (or to be sent) and received on the wire
@@ -412,20 +412,20 @@ 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 InitiatorFinished
- or ReceiverFinished 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>InitiatorFinished <- HMAC(fk<sub>I</sub>, InitiatorHello...ReceiverHello)</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>ReceiverFinished <- HMAC(fk<sub>R</sub>, InitiatorHello...ReceiverHello*)</li>
+ <li>RFinished <- HMAC(fk<sub>R</sub>, H(T({ServicesInfo,c_I}))</li>
</ol>
<t>
- Observe how the ReceiverFinished transcript used as input into the HMAC cannot include
- the ReceiverFinished 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">
@@ -519,20 +519,20 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
+-----+-----+-----+-----+-----+-----+-----+-----+
| r_R |
+-----+-----+-----+-----+-----+-----+-----+-----+
- / {ServicesInfo,c_I}{ReceiverFinished} /
+ / {ServicesInfo,c_I}{RFinished} /
]]></artwork>
</figure>
<t>
The protected fields after the nonce are encrypted using a key derived from AHTS.
- The ReceiverFinished is encrypted individually.
+ The RFinished is encrypted individually.
This is because the transcript of the ReceiverHello to generate the
- ReceiverFinished 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 InitiatorFinished 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>
