proposal updates 123,136,137

i2p2www/spec/proposals/123-new-netdb-entries.rst

@@ -5,7 +5,7 @@ New netDB Entries
     :author: zzz
     :created: 2016-01-16
     :thread: http://zzz.i2p/topics/2051
-    :lastupdated: 2016-01-16
+    :lastupdated: 2017-11-12
     :status: Open
     :supercedes: 110, 120, 121, 122
 
@@ -140,6 +140,57 @@ Flag definition::
 
 Properties is for future use, no current plans.
 
+
+Justification
+`````````````
+
+- Published: Replaces the complex logic required to determine the 'version' of the
+  leaseset. Currently, the version is the expiration of the last-expiring lease,
+  and a publishing router must increment that expiration by at least 1ms when
+  publishing a leaseset that only removes an older lease.
+- Expires: Allows for an expiration of a netdb entry to be earlier than that of
+  its last-expiring leaseset. May not be useful for LS2, where leasesets
+  are expected to remain with a 11-minute maximum expiration, but
+  for other new types, it is necessary (see Meta LS and Service Record below).
+  Max is about 49.7 days.
+- Flags: For future expansion, and the unpublished/published bit.
+- Unpublished/published: For use when sending a database store end-to-end,
+  the sending router may wish to indicate that this leaseset should not be
+  sent to others. We currently use heuristics to maintain this state.
+- Properties: Future expansion
+
+
+Discussion
+``````````
+
+This proposal continues to use the public key in the leaseset for the
+end-to-end encryption key, and leaves the public key field in the
+Destination unused, as it is now. The encryption type is not specified
+in the Destination key certificate, it will remain 0.
+
+Possible extension: Optionally include multiple encryption type/public key pairs,
+to ease transition to new encryption types.
+
+An alternative is to specify the encryption type in the Destination key certificate,
+use the public key in the Destination, and not use the public key
+in the leaseset. A formal proposal for this is in progress.
+
+Benefits of LS2:
+- Location of actual public key doesn't change.
+- Encryption type, or public key, may change without changing the Destination.
+- Removes unused revocation field
+- Basic compatibility with other DatabaseEntry types in this proposal
+- Could allow multiple encryption types
+
+Drawbacks of LS2:
+- Location of public key and encryption type differs from RouterInfo
+- Maintains unused public key in leaseset
+- Requires implementation across the network; in the alternative, experimental
+  encryption types may be used, if allowed by floodfills
+  (but see related proposals 136 and 137 about support for experimental sig types).
+  The alternative proposal could be easier to implement and test for experimental encryption types.
+
+
 Notes
 `````
 - Should we reduce the 8-byte expiration in leases to a 2-byte offset from the

i2p2www/spec/proposals/136-experimental-sigtypes.rst

@@ -5,7 +5,7 @@ Floodfill Support for Experimental Sig Types
     :author: zzz
     :created: 2017-03-31
     :thread: http://zzz.i2p/topics/2279
-    :lastupdated: 2017-03-31
+    :lastupdated: 2017-11-12
     :status: Open
 
 .. contents::
@@ -28,7 +28,7 @@ The GOST proposal 134 has revealed two issues with the previously-unused experim
 First, since sig types in the experimental range cannot be reserved, they may be used for
 multiple sig types at once.
 
-Second, unless a lease set with an experimental sig type can be stored at a floodfill,
+Second, unless a router info or lease set with an experimental sig type can be stored at a floodfill,
 the new sig type is difficult to fully test or use on a trial basis.
 
 
@@ -59,7 +59,7 @@ Additionally, a floodfill should overwrite an experimental netdb entry
 with a store of a non-experimental sig type that is a hash collision,
 to prevent hijacking of a previously-absent hash.
 
-Floodfills should assume the public key length is 256, or derive it from
+Floodfills should assume the signing public key length is 128, or derive it from
 the key certificate length, if longer. Some implementations may
 not support longer lengths unless the sig type is informally reserved.
 
@@ -77,10 +77,22 @@ will fail, but that's the same as it is now.
 Issues
 ======
 
-There may be additional security implications, to be researched.
+There may be additional security implications, to be researched (see proposal 137)
 
-Some implementations may not support key lengths greater than 256,
-as described above.
+Some implementations may not support key lengths greater than 128,
+as described above. Additionally, it may be necessary to enforce a maximum of 128
+(in other words, there is no excess key data in the key cert),
+to reduce the ability of attackers to generate hash collisions.
+
+Similar issues will need to be addressed with non-zero encryption types,
+which has not yet been formally proposed.
+
+
+Notes
+=====
+
+NetDB stores of unknown sig types that are not in the experimental range will continue
+to be rejected by floodfills, as the signature cannot be verified.
 
 
 See Also

i2p2www/spec/proposals/137-optional-sigtypes.rst

@@ -5,7 +5,7 @@ Floodfill Support for Optional Sig Types
     :author: zzz
     :created: 2017-03-31
     :thread: http://zzz.i2p/topics/2280
-    :lastupdated: 2017-03-31
+    :lastupdated: 2017-11-12
     :status: Open
 
 .. contents::
@@ -28,7 +28,7 @@ The GOST proposal 134 has revealed several issues with the previously-unused exp
 First, since sig types in the experimental range cannot be reserved, they may be used for
 multiple sig types at once.
 
-Second, unless a lease set with an experimental sig type can be stored at a floodfill,
+Second, unless a router info or lease set with an experimental sig type can be stored at a floodfill,
 the new sig type is difficult to fully test or use on a trial basis.
 
 Third, if proposal 136 is implemented, this is not secure, as anybody can overwrite an entry.
@@ -58,7 +58,10 @@ Specification
 Ref: http://i2p-projekt.i2p/en/docs/spec/common-structures
 http://i2p-projekt.i2p/en/docs/spec/i2np
 
-Add a RI property with comma-separated sig type numbers.
+A router that supports an optional sig type shall add "sigTypes" property
+to its published router info, with comma-separated sig type numbers.
+The sig types will be in sorted numerical order.
+Mandatory sig types (0-4,7) shall not be included.
 
 For example: sigTypes=9,10
 
@@ -71,7 +74,7 @@ Migration
 =========
 
 Not applicable.
-Only routers that support the optional sig type must implement.
+Only routers that support an optional sig type must implement.
 
 
 
@@ -80,6 +83,18 @@ Issues
 
 If there are not a lot of floodfills supporting the sig type, they may be difficult to find.
 
+It may not be necessary to require ECDSA 384 and 521 (sig types 2 and 3) for all floodfills.
+These types are not widely used.
+
+Similar issues will need to be addressed with non-zero encryption types,
+which has not yet been formally proposed.
+
+
+Notes
+=====
+
+NetDB stores of unknown sig types that are not in the experimental range will continue
+to be rejected by floodfills, as the signature cannot be verified.
 
 
 See Also