ratchet updates

i2p2www/spec/ecies.rst

@@ -182,6 +182,44 @@ Bound sessions are similar to the Noise IK pattern.
 {% endhighlight %}
 
 
+Security Properties
+```````````````````
+
+Using Noise terminology, the establishment and data sequence is as follows:
+(Payload Security Properties from [Noise]_ )
+
+.. raw:: html
+
+  {% highlight lang='text' %}
+IK(s, rs):           Authentication   Confidentiality
+    <- s
+    ...
+    -> e, es, s, ss           1                2
+    <- e, ee, se              2                4
+    ->                        2                5
+    <-                        2                5
+{% endhighlight %}
+
+
+Differences From XK
+```````````````````
+IK handshakes have several differences from XK handshakes used
+in [NTCP2]_ and [SSU2]_.
+
+- Four total DH operations compared to three for XK
+- Sender authentication in first message: The payload is authenticated
+  as belonging to the owner of the sender's public key, although
+  the key could have been compromised (Authentication 1)
+  XK requires another round trip before Alice is authenticated.
+- Full forward secrecy (Confidentiality 5) after the second message.
+  Bob may send a payload immediately after the second message with
+  full forward secrecy.
+  XK requires another round trip for full forward secrecy.
+
+In summary, IK allows 1-RTT delivery of the response payload from Bob to Alice
+with full forward secrecy, however the request payload is not forward-secret.
+
+
 Sessions
 --------
 
@@ -3018,7 +3056,7 @@ If the timer does fire, send an empty payload with the NSR or ES.
 
 
 
-Protocol-layer Responses
+Ratchet-layer Responses
 ````````````````````````
 
 Initial implementations rely on bidirectional traffic at the higher layers.
@@ -3031,7 +3069,7 @@ such that there is no higher-layer traffic to generate a timely response.
 Receipt of NS and NSR messages require a response;
 receipt of ACK Request and Next Key blocks also require a response.
 
-A sophisticated implementation may start a timer when one of these
+Implementations should start a timer when one of these
 messages is received which requires a response,
 and generate an "empty" (no Garlic Clove block) response
 at the ECIES layer
@@ -3042,6 +3080,51 @@ responses to NS and NSR messages, to shift the traffic to
 the efficient ES messages as soon as possible.
 
 
+NS Binding For NSR
+``````````````````
+
+At the ratchet layer, as Bob, Alice is only known by static key.
+The NS message is authenticated ([Noise]_ IK sender authentication 1).
+However, this is not sufficient for the ratchet layer to be able to send anything
+to Alice, as network routing requires a full Destination.
+
+Before the NSR may be sent, Alice's full Destination must be discovered either
+by the ratchet layer or a higher-layer repliable protocol,
+either repliable [Datagrams]_ or [Streaming]_.
+After finding the Leaseset for that Destination, that Leaseset
+will contain the same static key as contained in the NS.
+
+Typically, the higher layer will respond, forcing a network database
+lookup of Alice's Leaseset by Alice's Destination Hash.
+That Leaseset will almost always be found locally, because the
+NS contained a Garlic Clove block, containing a Database Store message,
+containing Alice's Leaseset.
+
+For Bob to be prepared to send a ratchet-layer NSR, and to bind
+the pending session to Alice's Destination, Bob should
+"capture" the Destination while processing the NS payload.
+If a Database Store message is found containing a Leaseset
+with a key matching the static key in the NS,
+the pending session is now bound to that Destination,
+and Bob knows where to send any NSR if the response timer expires.
+This is the recommended implementation.
+
+An alternative design is to maintain a cache or database
+where the static key is mapped to a Destination.
+The security and practicality of this approach
+is a topic for further study.
+
+Neither this specification nor others strictly require that
+every NS contains Alice's Leaseset.
+However, in practice, it should.
+The recommended ES tagset sender timeout (8 minutes)
+is shorter than the maximum Leaseset timeout (10 minutes),
+so there could be a small window where the previous session
+has expired, Alice thinks that Bob
+still has her valid Leaseset, and does not send a new Leaseset
+with the new NS. This is a topic for further study.
+
+
 Multiple NS Messages
 ````````````````````
 
@@ -3168,6 +3251,9 @@ References
 .. [CRYPTO-ELG]
     {{ site_url('docs/how/cryptography', True) }}#elgamal
 
+.. [Datagrams]
+    {{ spec_url('datagrams') }}
+
 .. [Elligator2]
     https://elligator.cr.yp.to/elligator-20130828.pdf
     https://www.imperialviolet.org/2013/12/25/elligator.html
@@ -3239,6 +3325,12 @@ References
 .. [SSU]
     {{ site_url('docs/transport/ssu', True) }}
 
+.. [SSU2]
+    {{ spec_url('ssu2') }}
+
+.. [Streaming]
+    {{ spec_url('streaming') }}
+
 .. [STS]
     Diffie, W.; van Oorschot P. C.; Wiener M. J., Authentication and
     Authenticated Key Exchanges

i2p2www/spec/ntcp2.rst

@@ -3,8 +3,8 @@ NTCP 2
 ======
 .. meta::
     :category: Transports
-    :lastupdated: 2024-01
-    :accuratefor: 0.9.61
+    :lastupdated: 2025-04
+    :accuratefor: 0.9.66
 
 .. contents::
 
@@ -110,7 +110,7 @@ Alice                           Bob
 {% endhighlight %}
 
 Using Noise terminology, the establishment and data sequence is as follows:
-(Payload Security Properties)
+(Payload Security Properties from [Noise]_ )
 
 .. raw:: html
 
@@ -368,7 +368,7 @@ Noise content: Alice's ephemeral key X
 Noise payload: 16 byte option block
 Non-noise payload: Random padding
 
-(Payload Security Properties)
+(Payload Security Properties from [Noise]_ )
 
 .. raw:: html
 
@@ -703,7 +703,7 @@ Noise content: Bob's ephemeral key Y
 Noise payload: 16 byte option block
 Non-noise payload: Random padding
 
-(Payload Security Properties)
+(Payload Security Properties from [Noise]_ )
 
 .. raw:: html
 
@@ -992,7 +992,7 @@ Noise content: Alice's static key
 Noise payload: Alice's RouterInfo and random padding
 Non-noise payload: none
 
-(Payload Security Properties)
+(Payload Security Properties from [Noise]_ )
 
 
 .. raw:: html
@@ -1267,7 +1267,7 @@ Types include date/time, I2NP message, options, termination, and padding.
 Note: Bob may, but is not required, to send his RouterInfo to Alice as
 his first message to Alice in the data phase.
 
-(Payload Security Properties)
+(Payload Security Properties from [Noise]_ )
 
 
 .. raw:: html