Ambiguous Places in I2P Specifications:
While the I2P specifications are comprehensive, I found a few areas that could benefit from clarification or further detail:
1. Common Structures:
Key Certificate Padding Generation Guidelines (KeysAndCert): The guidelines suggest a minimum of 32 bytes of random data for ElG public key and padding fields, but the exact distribution and repetition pattern of this data is not explicitly defined, leaving room for interpretation by implementers.
Mapping (Duplicate Keys): While the encoding allows duplicate keys, the document mentions potential signature failures and application-dependent behavior. A clearer stance on duplicate keys and their handling would be beneficial.
RouterAddress (Expiration): The document mentions that the expiration field is currently unused and assumed zero, but also states that a non-zero expiration is again recognized. This inconsistency may cause confusion about the current status and future plans for this field.
2. Low-Level Cryptography:
ElGamal (Short Exponent Obsolescence): The document mentions the vulnerability of the short exponent and the need for further study, but doesn't provide a clear timeline or plan for transitioning to a longer exponent.
AES (Obsolescence): Similar to ElGamal, the document mentions the need to study the vulnerability of AES and potential transition, but lacks concrete plans or timelines.
3. Plugin Specification:
Eepsite Integration: The document states that plugin installation into existing eepsites is unclear. Providing specific examples or guidelines for achieving this would be helpful for developers.
Shell Script/External Program Execution: While the document mentions using ShellCommand for execution, additional details on handling process termination and preventing multiple instances would be valuable.
4. Tunnel Creation Specification:
Number of Records (Future Work): The document suggests the possibility of utilizing the remaining record in the VTBM for increased efficiency, but it requires further research and verification. Providing updates on this research and its potential impact on the protocol would be helpful.
Hop Processing and Encryption (Tagging/Timing Attacks): The document mentions potential tagging and timing attacks, but doesn't provide concrete solutions or mitigation strategies. Further analysis and clarification are needed.
5. Tunnel Message Specification:
Cover Traffic: The document mentions the possibility of cover traffic using padding-only messages, but it is marked as unimplemented. Clarifying the status and future plans for cover traffic would be beneficial.
6. NTCP2:
Padding Guidelines: The document mentions the need for minimum/maximum padding guidelines for several message types, but does not provide concrete values or recommendations.
7. SSU2:
Padding and Options: Similar to NTCP2, the document mentions the need for padding strategies and minimum padding, along with options negotiation and defaults, which are all marked as TBD. Providing more concrete details in these areas would improve clarity.
Connection Migration (Routing): The document discusses the challenge of routing data packets during path validation and suggests potential strategies, but doesn't provide a definitive recommendation or implementation details.
8. ECIES-X25519-AEAD-Ratchet:
Multicast: This feature is marked as TBD, and further details on its implementation and functionality would be helpful.
Protocol-layer Responses: The document suggests implementing timers for generating responses when no reverse traffic is present, but the specific timeout values and implementation details are left open for interpretation.
9. Streaming Protocol Specification:
Replay Prevention: While the document specifies a mechanism to prevent replay attacks using the NACKs field, it is unclear how this interacts with existing replay prevention mechanisms at other protocol layers.
10. Encrypted LeaseSet Specification:
Encrypted LS with Offline Keys: The document mentions the need for a file format and I2CP protocol enhancements to support offline keys, but doesn't provide any specific proposals or details.
General Observations:
Several specifications mention the need for further research or study of specific features or vulnerabilities, but lack clear timelines or plans for addressing these issues.
Certain parameters and timeout values are marked as TBD or left for implementation-dependent decisions, potentially leading to inconsistencies across different implementations.
Clarifying the compatibility and support for different versions of the protocols across various I2P implementations would be helpful for developers and users.
Overall, while the I2P specifications are extensive and well-structured, addressing the ambiguities identified above would further enhance clarity, consistency, and interoperability across different implementations.