proposals 136,137

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

+============================================
+Floodfill Support for Experimental Sig Types
+============================================
+.. meta::
+    :author: zzz
+    :created: 2017-03-31
+    :thread: http://zzz.i2p/topics/2279
+    :lastupdated: 2017-03-31
+    :status: Open
+
+.. contents::
+
+
+Overview
+========
+
+For sig types in the experimental range (65280-65534),
+floodfills should accept netdb stores without checking the signature.
+
+This will support testing of new sig types.
+
+
+Motivation
+==========
+
+The GOST proposal 134 has revealed two issues with the previously-unused experimental sig type range.
+
+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,
+the new sig type is difficult to fully test or use on a trial basis.
+
+
+
+Design
+======
+
+Floodfills should accept, and flood, LS stores with sig types in the experimental range,
+without checking the signature. Support for RI stores is TBD, and may have more security implications.
+
+
+
+Specification
+=============
+
+Ref: http://i2p-projekt.i2p/en/docs/spec/common-structures
+http://i2p-projekt.i2p/en/docs/spec/i2np
+
+For sig types in the experimental range, a floodfill should accept and flood netdb
+stores without checking the signature.
+
+To prevent spoofing of non-experimental routers and destinations, a floodfill
+should never accept a store of an experimental sig type that has a hash
+collision with an existing netdb entry of a different sig type.
+This prevents hijacking of a previous netdb entry.
+
+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
+the key certificate length, if longer. Some implementations may
+not support longer lengths unless the sig type is informally reserved.
+
+
+Migration
+=========
+
+Once this feature is supported, in a known router version,
+experimental sig type netdb entries may be stored to floodfills of that version or higher.
+
+If some router implementations do not support this feature, the netdb store
+will fail, but that's the same as it is now.
+
+
+Issues
+======
+
+There may be additional security implications, to be researched.
+
+Some implementations may not support key lengths greater than 256,
+as described above.
+
+
+See Also
+========
+
+Proposal 134
+Proposal 137

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

+========================================
+Floodfill Support for Optional Sig Types
+========================================
+.. meta::
+    :author: zzz
+    :created: 2017-03-31
+    :thread: http://zzz.i2p/topics/2280
+    :lastupdated: 2017-03-31
+    :status: Open
+
+.. contents::
+
+
+Overview
+========
+
+Add a way for floodfills to advertise support for optional sig types.
+This will provide a way to support new sig types over the long-term,
+even if not all implementations support them.
+
+
+
+Motivation
+==========
+
+The GOST proposal 134 has revealed several issues with the previously-unused experimental sig type range.
+
+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,
+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.
+
+Fourth, implementing a new sig type can be a large development effort.
+It may be difficult to convince developers for all router implementations to add support for a new
+sig type in time for any particular release. Developer's time and motivations may vary.
+
+Fifth, if GOST uses a sig type in the standard range, there's still no way to know if a particular
+floodfill supports GOST.
+
+
+
+Design
+======
+
+All floodfills must support sig types DSA (0), ECDSA (1-3), and EdDSA (7).
+
+For any other sig type in the standard (non-experimental) range, a floodfill may
+advertise support in its router info properties.
+
+
+
+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.
+
+For example: sigTypes=9,10
+
+Routers that support optional sig types must only store, lookup, or flood,
+to floodfills that advertise support for that sig type.
+
+
+
+Migration
+=========
+
+Not applicable.
+Only routers that support the optional sig type must implement.
+
+
+
+Issues
+======
+
+If there are not a lot of floodfills supporting the sig type, they may be difficult to find.
+
+
+
+See Also
+========
+
+Proposal 134
+Proposal 136