proposal updates

i2p2www/spec/proposals/144-ecies-x25519-aead-ratchet.rst

@@ -5,7 +5,7 @@ ECIES-X25519-AEAD-Ratchet
     :author: zzz, chisana
     :created: 2018-11-22
     :thread: http://zzz.i2p/topics/2639
-    :lastupdated: 2020-03-29
+    :lastupdated: 2020-03-31
     :status: Open
 
 .. contents::
@@ -2651,7 +2651,7 @@ Issues
 
 Ack
 ```
-This is only if an explicit ack was requested by the far end.
+This is only sent if an ack request block was received.
 Multiple acks may be present to ack multiple messages.
 
 
@@ -2688,35 +2688,25 @@ Issues
 
 Ack Request
 ```````````
-Delivery instructions for the ack.
+Request an in-band ack.
 To replace the out-of-band DeliveryStatus Message in the Garlic Clove.
-Also (optionally) binds the outbound session to the far-end Destination or Router.
 
-If an explicit ack is requested, the current key ID and message number (N)
+If an explicit ack is requested, the current tagset ID and message number (N)
-are returned in an ack block. When a next public key is included,
+are returned in an ack block.
-any message sent to that key constitutes an ack, no explicit ack is required.
 
 
 
 .. raw:: html
 
   {% highlight lang='dataspec' %}
-+----+----+----+----+----+----+----+----+
++----+----+----+----+
-  |  9 |  size   |tagsetid |flg |         |
+  |  9 |  size   |flg |
-  +----+----+----+----+----+----+         +
+  +----+----+----+----+
-     Garlic Clove Delivery Instructions   |
-  ~               .   .   .               ~
-  |            optional if flag is 1      |
-  +----+----+----+----+----+----+----+----+
 
   blk :: 9
-  size :: varies, typically 3 or 36
+  size :: 1
-  tagsetid :: key ID, 2 bytes, big endian
   flg :: 1 byte flags
-         bit order: 76543210
          bits 7-0: Unused, set to 0 for future compatibility
-  Delivery Instructions :: as defined in I2NP spec, 33 bytes for DESTINATION type
-
 
 {% endhighlight %}
 
@@ -2726,33 +2716,12 @@ Notes
 
 - Not allowed in NS or NSR. Only included in Existing Session mnessages
 
-- tagsetid is known to receiver, TBD to remove
-
-- Delivery Instructions unused, TBD to remove
-
-- Interaction with next key TBD
-
-- When the delivery instructions contains the hash of the destination,
-  and the session is not previously bound, this binds the session to the destination.
-
-- After a session is bound, any subsequent destination delivery instructions must contain
-  the same hash as previously, or this is an error.
-
 - See ACK section above for more information.
 
 
 Issues
 ``````
 
-- Java router must have the actual signing private key, not a dummy,
-  see new I2CP Create LeaseSet2 Message in proposal 123.
-
-- For easier processing, LS clove should precede Garlic clove in the message.
-
-- Is the next public key the right thing to sign?
-
-- Use alice's static pubkey instead?
-
 
 
 Padding

i2p2www/spec/proposals/154-ecies-lookups.rst

@@ -5,7 +5,7 @@ Database Lookups from ECIES Destinations
     :author: zzz
     :created: 2020-03-23
     :thread: http://zzz.i2p/topics/2856
-    :lastupdated: 2020-03-29
+    :lastupdated: 2020-03-31
     :status: Open
 
 .. contents::
@@ -123,14 +123,15 @@ Add flag bit 4 "ECIESFlag" for the new encryption options.
   {% highlight lang='dataspec' %}
 flags ::
        bit 4: ECIESFlag
-               before release 0.9.TBD, ignored
+               before release 0.9.46 ignored
-               as of release 0.9.TBD:
+               as of release 0.9.46:
                0  => send unencrypted or ElGamal reply
-               1  => send ECIES encrypted reply using enclosed key and tag
+               1  => send ChaCha/Poly encrypted reply using enclosed key
+                     (whether tag is enclosed depends on bit 1)
 {% endhighlight %}
 
 Existing flag bit 1 used in combination with bit 4 to determine the reply encryption mode.
-Flag bit 4 must only be set when sending to routers with version 0.9.TBD or higher.
+Flag bit 4 must only be set when sending to routers with version 0.9.46 or higher.
 
 
 =============  =========  =========  ======  ===  =======
@@ -189,6 +190,7 @@ ECIES to ElG
 ------------
 
 ECIES destination sends a lookup to a ElG router.
+Supported as of 0.9.46.
 
 The reply_key and reply_tags fields are redefined for an ECIES-encrypted reply.
 
@@ -209,17 +211,17 @@ Redefine reply_key and reply_tags fields as follows:
   {% highlight lang='dataspec' %}
 reply_key ::
        32 byte ECIES `SessionKey` big-endian
-       only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
+       only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.46
 
   tags ::
        1 byte `Integer`
        required value: 1
        the number of reply tags that follow
-       only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
+       only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.46
 
   reply_tags ::
        an 8 byte ECIES `SessionTag`
-       only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
+       only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.46
 
 {% endhighlight %}
 
@@ -234,7 +236,7 @@ tag :: 8 byte reply_tag
   k :: 32 byte session key
      The reply_key.
 
-  n :: The index of the reply_tag. Typically 0.
+  n :: 0
 
   ad :: Associated data. ZEROLEN.
 
@@ -252,6 +254,7 @@ ECIES to ECIES
 --------------
 
 ECIES destination sends a lookup to a ECIES router.
+Supported as of 0.9.TBD.
 
 The lookup will use the "one time format" in [ECIES]_
 as the requester is anonymous.
@@ -383,6 +386,8 @@ The above proposal is the easiest and minimizes the change to the lookup format.
 Notes
 =====
 
+Database lookups and stores to ElG routers must be ElGamal/AESSessionTag encrypted
+as usual.
 
 
 Issues
@@ -395,11 +400,12 @@ Further analysis is required on the security of the two ECIES reply options.
 Migration
 =========
 
-No backward compatibility issues. Routers advertising a router.version of 0.9.TBD or higher
+No backward compatibility issues. Routers advertising a router.version of 0.9.46 or higher
 in their RouterInfo must support this feature.
-Routers must not send a DatabaseLookup with the new flags to routers with a version less than 0.9.TBD.
+Routers must not send a DatabaseLookup with the new flags to routers with a version less than 0.9.46.
-
+If a database lookup message with bit 4 set and bit 1 unset is mistakenly sent to
-
+a router without support, it will probably ignore the supplied key and tag, and
+sent the reply unencrypted.
 
 References
 ==========