--- layout: post title: Overview and Logs for the tini2p Dev Meeting Held on 2019-08-08 summary: Current project status, Roadmap, Meta issues, and miscellaneous tags: [dev diaries, i2p, crypto] author: el00ruobuob / oneiric --- # Logs **\** 0: Greetings **\** hi **\** 1: What's been done **\** Reworked a BuildRequestRecord, BuildReplyRecord, and TunnelBuildMessage to be templated based on symmetric crypto used (AES/ChaCha20) **\** reorged the commits, because the changes were verbose, and most (if not all) were for code added in the `tunnels` branch **\** Added `Hop`and `OutboundGateway` classes for tunnel message processing **\** `OutboundGateway` is still WIP, and will hopefully be finishing up today **\** didn't get nearly as much done as I had hoped, so scaling back my expectations a bit **\** going to push back alpha release two weeks **\** 2: What's next **\** will be finishing `OutboundGateway`, and implementing `OutboundEndpoint`, `InboundGateway`, and `InboundEndpoint` **\** those are the last of the message processing classes **\** dev is somewhat slow because I'm implementing AES + ChaCha tunnels simultaneously (which adds some headache), but it should be worth it in the long-term **\** ultimately, I think it is faster to do both simultaneously **\** after the processing classes, I'll start implementing tunnel pools and management classes **\** given the experience of the past couple weeks, pools + management could take a week each, so alpha may actually be a month away **\** hopefully not, and I'll do my best to complete them correctly as fast as possible. correctness takes priority over speed, though **\** 3: ECIES Status **\** development and discussion on 144 continues **\** there has been progress over the last couple meetings, and hopefully we're getting closer to consensus on what 144 goals + spec should be **\** zzz is insistent on unlimited 0-RTT messages, and reusing ephemeral key data for cached DH results **\** I think both are bad ideas **\** unlimited 0-RTT messages opens an attack vector for never completing the handshake, where a mitm on the reply tunnel drops Bob's New Session Reply messages **\** or allows the reply messages through, but blocks Alice's Existing Session messages **\** reusing ephemeral key data could lead to the same symmetric key being used to encrypt the New Session and New Session Reply payload sections **\** in a version of the spec that sends multiple New Session (Reply) messages, encrypting different payload sections with the same key material breaks ChaCha20-Poly1305 **\** it's a fragile scheme, that requires a lot of analysis and care to get right **\** I'm proposing that instead of sending unlimited New Session and New Session Reply messages, we send one each, including up to the maximum data for one payload section (~60KB) **\** until the New Session Reply is received by Alice, she will drop any other messages from the client destined for Bob **\** somewhat outside the protocol, I'm suggesting Alice's router send a "please resend in X seconds/minutes" as a reply to the client until the session is established **\** similarly, if Bob's initial reply is too large to fit in one Payload section, Bob will send a "please resend after session established" message to Alice **\** Alice can then send a "reply was too large for initial message, please retry the request" **\** ^ can send that to the client **\** alternatively, Alice and Bob could queue messages until session establishment, but that could lead to resource exhaustion. less desirable and less secure **\** latest I2P LS2 meeting log: https://gitlab.com/tini2p/meta/issues/26 **\** I'll likely be implementing the drop-until-secure, single New Session (Reply) scheme until we come to consensus on what to do **\** 4: Next meeting **\** 2019-08-22 18:00 UTC **\** @tini2p\_gitlab juggles baffer like a hacky sack **\** thinking further about the "resend request" message Bob sends when the reply is too large for a single payload section, Bob could include the original request in the message **\** Alice could then extract the request, and resend in the first Existing Session message