diff --git a/i2p2www/spec/proposals/136-experimental-sigtypes.rst b/i2p2www/spec/proposals/136-experimental-sigtypes.rst new file mode 100644 index 0000000000000000000000000000000000000000..759b3421510356c6b7aec787a1704cfe00bcae1b --- /dev/null +++ b/i2p2www/spec/proposals/136-experimental-sigtypes.rst @@ -0,0 +1,90 @@ +============================================ +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 diff --git a/i2p2www/spec/proposals/137-optional-sigtypes.rst b/i2p2www/spec/proposals/137-optional-sigtypes.rst new file mode 100644 index 0000000000000000000000000000000000000000..b6f6e563afd48b715630b7ee0defa58e96c4d889 --- /dev/null +++ b/i2p2www/spec/proposals/137-optional-sigtypes.rst @@ -0,0 +1,89 @@ +======================================== +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