New proposal 157; add references to it in 152 and 256

i2p2www/spec/proposals/152-ecies-tunnels.rst

@@ -6,7 +6,7 @@ ECIES Tunnels
     :author: chisana, zzz, orignal
     :created: 2019-07-04
     :thread: http://zzz.i2p/topics/2737
-    :lastupdated: 2020-09-23
+    :lastupdated: 2020-10-09
     :status: Open
     :target: 0.9.51
 
@@ -84,6 +84,7 @@ Non-Goals
 - Shrinking tunnel build messages (requires all-ECIES hops and a new proposal)
 - Use of tunnel build options as defined in [Prop143]_, only required for small messages
 - Bidirectional tunnels - for that see [Prop119]_
+- Smaller tunnel build messages - for that see [Prop157]_
 
 
 Threat Model
@@ -837,6 +838,9 @@ References
 .. [Prop156]
     {{ proposal_url('156') }}
 
+.. [Prop157]
+    {{ proposal_url('157') }}
+
 .. [Tunnel-Creation]
    {{ spec_url('tunnel-creation') }}
 

i2p2www/spec/proposals/156-ecies-routers.rst

@@ -5,7 +5,7 @@ ECIES Routers
     :author: zzz, orignal
     :created: 2020-09-01
     :thread: http://zzz.i2p/topics/2950
-    :lastupdated: 2020-09-05
+    :lastupdated: 2020-10-09
     :status: Open
     :target: 0.9.51
 
@@ -46,6 +46,7 @@ See [Prop152]_ for additional goals.
 - Maximize compatibility with current network
 - Do not require "flag day" upgrade to entire network
 - Gradual rollout to minimize risk
+- New, smaller tunnel build message
 
 
 Non-Goals
@@ -54,7 +55,7 @@ Non-Goals
 See [Prop152]_ for additional non-goals.
 
 - No requirement for dual-key routers
-- Complete redesign of tunnel build messages requiring a "flag day", for that see [Prop153]_
+- Layer encryption changes, for that see [Prop153]_
 
 
 Design
@@ -92,9 +93,17 @@ are required to use ECIES instead of ElGamal.
 In addition, we will make improvements to the tunnel build messages
 to increase security.
 
+In phase 1, we will change the format and encryption of the
+Build Request Record and Build Response Record for ECIES hops.
+These changes will be compatible with existing ElGamal routers.
 These changes are defined in proposal 152 [Prop152]_.
-Proposal 152 is preliminary and has not been fully reviewed.
-It will require significant corrections and cleanup.
+
+In phase 2, we will add a new version of the
+Build Request Message, Build Reply Message,
+Build Request Record and Build Response Record.
+The size will be reduced for efficiency.
+These changes must be supported by all hops in a tunnel, and all hops must be ECIES.
+These changes are defined in proposal 157 [Prop157]_.
 
 
 
@@ -147,6 +156,7 @@ Tunnel Building: See [Prop152]_.
 
 End-to-End Encryption: See [ECIES]_.
 
+New Tunnel Build Message: See [Prop157]_.
 
 
 Justification
@@ -255,6 +265,18 @@ Probably start rekeying mid-2021.
 Target release: TBD
 
 
+New Tunnel Build Message
+--------------------------
+
+Implement and test the new Tunnel Build Message.
+Roll the support out in a release.
+Do additional testing, then enable it in the next release.
+
+Probably mid-2021.
+
+Target release: TBD
+
+
 ECIES for New Installs
 --------------------------
 
@@ -306,6 +328,9 @@ References
 .. [Prop154]
     {{ proposal_url('154') }}
 
+.. [Prop157]
+    {{ proposal_url('157') }}
+
 .. [Tunnel-Creation]
     {{ spec_url('tunnel-creation') }}
 

i2p2www/spec/proposals/157-new-tbm.rst

+========================================
+Smaller Tunnel Build Messages
+========================================
+.. meta::
+    :author: zzz, orignal
+    :created: 2020-10-09
+    :thread: http://zzz.i2p/topics/2957
+    :lastupdated: 2020-10-09
+    :status: Open
+    :target: 0.9.51
+
+.. contents::
+
+
+
+Overview
+========
+
+
+Summary
+-------
+
+The current size of the encrypted tunnel Build Request and Response records is 528.
+For typical Variable Tunnel Build and Variable Tunnel Build Reply messages,
+the total size is 2113 bytes. This message is fragmented into 1KB three tunnel
+messages for the reverse path.
+
+Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152]_.
+For a mix of ElGamal and ECIES-X25519 routers in a tunnel, the record size must remain
+528 bytes. However, if all routers in a tunnel are ECIES-X25519, a new, smaller
+build record is possible, because ECIES-X25519 encryption has much less overhead
+than ElGamal.
+
+Smaller messages would save bandwidth. Also, if the messages could fit in a
+single tunnel message, the reverse path would be three times more efficient.
+
+This proposal defines new request and reply records and new Buid Request and Build Reply messages.
+
+
+Goals
+-----
+
+See [Prop152]_ and [Prop156]_ for additional goals.
+
+- Smaller records and messages
+- Maintain sufficient space for future options, as in [Prop152]_
+- Fit in one tunnel message for the reverse path
+- Support ECIES hops only
+- Maintain improvements implemented in [Prop152]_
+- Maximize compatibility with current network
+- Do not require "flag day" upgrade to entire network
+- Gradual rollout to minimize risk
+- Reuse existing cryptographic primitives
+
+
+Non-Goals
+-----------
+
+See [Prop156]_ for additional non-goals.
+
+- No requirement for mixed ElGamal/ECIES tunnels
+- Layer encryption changes, for that see [Prop153]_
+- No speedups of crypto operations. It's assumed that ChaCha20 and AES are similar.
+
+
+Design
+======
+
+
+Records
+-------------------------------
+
+See appendix for calculations.
+
+Encrypted request and reply records will be 236 bytes, compared to 528 bytes now.
+
+The plaintext request records will be either 160 or 172 bytes,
+compared to 222 bytes for ElGamal records,
+and 464 bytes for ECIES records as defined in [Prop152]_.
+
+The plaintext response records will be either 160 or 172 bytes,
+compared to 496 bytes for ElGamal records,
+and 512 bytes for ECIES records as defined in [Prop152]_.
+
+If we use AES for reply encryption, records must be a multiple of 16.
+If we use ChaCha20 (NOT ChaCha20/Poly1305), they can be 172 bytes.
+TBD.
+
+Request records will be made smaller by using HKDF to create the
+layer and reply keys, so they do not need to be explicitly included in the request.
+
+
+Tunnel Build Messages
+-----------------------
+
+Both will be "variable" with a one-byte number of records field,
+as with the existing Variable messages.
+
+Build: Type 25
+
+Reply: Type 26
+
+Total length: 641 or 689 bytes
+
+
+Record Encryption
+------------------
+
+Request and reply record encryption: as defined in [Prop152]_.
+
+Reply record encryption for other slots: AES or ChaCha20?
+
+
+
+Specification
+=============
+
+
+Request Record
+-----------------------
+
+TBD
+
+
+Response Record
+-----------------------
+
+TBD
+
+
+KDF
+-----------------------
+
+TBD
+
+
+Tunnel Build Messages
+-----------------------
+
+TBD
+
+
+Justification
+=============
+
+This design maximizes reuse of existing cryptographic primitives, protocols, and code.
+
+This design minimizes risk.
+
+
+
+
+Implementation Notes
+=====================
+
+
+
+
+Issues
+======
+
+- HKDF details
+- AES or ChaCha for reply encryption?
+- Should we do additional hiding from the paired OBEP or IBGW? Garlic?
+
+
+Migration
+=========
+
+The implementation, testing, and rollout will take several releases
+and approximately one year. The phases are as follows. Assignment of
+each phase to a particular release is TBD and depends on
+the pace of development.
+
+Details of the implementation and migration may vary for
+each I2P implementation.
+
+Tunnel creator must ensure that all hops are ECIES-X25519, AND are at least version TBD.
+The tunnel creator does NOT have to be ECIES-X25519; it can be ElGamal.
+However, if the creator is ElGamal, it reveals to the closest hop that it is the creator.
+So, in practice, these tunnels should only be created by ECIES routers.
+
+It should NOT be necessary for the paired-tunnel OBEP or IBGW is ECIES or
+of any particular version, because they SHOULD support
+relaying of unknown message types.
+This should be verified in testing.
+
+Phase 1: Implementation, not enabled by default
+
+Phase 2 (next release): Enable by default
+
+
+Appendix
+==========
+
+
+.. raw:: html
+
+  {% highlight lang='text' %}
+Current 4-slot size: 4 * 528 + overhead = 3 tunnel messages
+
+  4-slot build message to fit in one tunnel message, ECIES-only:
+
+  1024
+  - 21 fragment header
+  ----
+  1003
+  - 39 unfragmented instructions
+  ----
+  964
+  - 16 I2NP header
+  ----
+  948
+  - 1 number of slots
+  ----
+  947
+  / 4 slots
+  ----
+  236 New encrypted build record size (vs. 528 now)
+  - 16 trunc. hash
+  - 32 eph. key
+  - 16 MAC
+  ----
+  172 cleartext build record max (vs. 222 now)
+
+  Current build record cleartext size before unused padding: 193
+
+  Removal of full router hash and HKDF generation of keys/IVs would free up plenty of room for future options.
+  If everything is HKDF, required cleartext space is about 82 bytes (without any options)
+
+
+
+{% endhighlight %}
+
+
+References
+==========
+
+.. [Common]
+    {{ spec_url('common-structures') }}
+
+.. [ECIES]
+   {{ spec_url('ecies') }}
+
+.. [I2NP]
+    {{ spec_url('i2np') }}
+
+.. [Prop123]
+    {{ proposal_url('123') }}
+
+.. [Prop144]
+    {{ proposal_url('144') }}
+
+.. [Prop145]
+    {{ proposal_url('145') }}
+
+.. [Prop152]
+    {{ proposal_url('152') }}
+
+.. [Prop153]
+    {{ proposal_url('153') }}
+
+.. [Prop154]
+    {{ proposal_url('154') }}
+
+.. [Prop156]
+    {{ proposal_url('156') }}
+
+.. [Tunnel-Creation]
+    {{ spec_url('tunnel-creation') }}
+