lsd0012

commit 5ebf138c555d68bb64421fd02d36f15a39f07aea
parent 30a10a5779b661020ea0dcb8823f540f8ec982d6
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Mon, 11 Nov 2024 22:47:48 +0100

open issues

Diffstat:
M
draft-schanzen-cake.xml
 | 
21
++++++++++++++++++---

1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -388,7 +388,7 @@ ss_I -> HKDF-Extract = Master Secret (MS)
         </ol>
       </section>
       <section anchor="third_message" numbered="true" toc="default">
-        <name>First Message</name>
+        <name>Third Message</name>
         <t>
           R sends to I the third message consisting of a <tt>MessageHeader</tt>,
           the <tt>InitiatorFinished</tt> message as defined
@@ -396,8 +396,7 @@ ss_I -> HKDF-Extract = Master Secret (MS)
         </t>
         <ol>
           <li>Verify that the message type is TBD</li>
-          <li>Setup Master Secret (MS) using ss<sub>e</sub> &lt;- Decaps(sk<sub>e</sub>,c<sub>e</sub>).</li>
-          <li>Derive Traffic Encryption Keys using <tt>HS</tt> and <tt>MS</tt>.</li>
+          <li>Setup remaining keys using ss<sub>e</sub> &lt;- Decaps(sk<sub>e</sub>,c<sub>e</sub>).</li>
           <li>fk<sub>I</sub> &lt;- HKDF-Expand(MS, "i finished", NULL)</li>
           <li>IF &lt;- HMAC(fk<sub>I</sub>, InitiatorHello...ReceiverFinished)</li>
           <li>fk<sub>R</sub> &lt;- HKDF-Expand(MS, "r finished", NULL)</li>
@@ -405,8 +404,24 @@ ss_I -> HKDF-Extract = Master Secret (MS)
           <li>assert HMAC(fk<sub>R</sub>, InitiatorHello...ReceiverKemCiphertext) == RF</li>
           <li>InitiatorFinished &lt;- Enc(IHTS, IF)</li>
         </ol>
+        <t>
+          At this point we have a secure channel.
+        </t>
       </section>
     </section>
+    <section anchor="open" numbered="true" toc="default">
+      <name>Open Issues</name>
+      <t>
+        Rekey
+      </t>
+      <t>
+    The Initiator/Receiver selection logic may require a timed fallback: The designates Initiator may never initiate (NAT, already has sufficient connections, learns about receiver later than receiver about initiator etc.).
+
+    This may result in edge cases where the Initiator initiates a handshake and the Receiver also initiates a handshake at the same time switching roles.
+
+    In such cases we may simply do both key exchanges. If both succeed, we drop the key exchange that was not initiated by the designated initiator on both peers. Otherwise we use the successful key exchange and the roles are swapped.
+      </t>
+    </section>
     <section anchor="security" numbered="true" toc="default">
       <name>Security and Privacy Considerations</name>
       <t>