#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

obscuratus In Java-I2P, when a peer disconnects from another SSU2 peer, the disconnected peers sends an acknowledgement, right? Is that acknowledgement an encrypted SSU2 packet?

zzz yes

zzz 0) Hi

zzz hi

orignal hi

eyedeekay hi

zzz what does everybody have for the list today?

eyedeekay In lieu of a `go-i2p` update this week I'd like to talk a little(or a lot) about naming

zzz ok 1) is naming

zzz I'll add 2) prop. 161 draft

zzz anything else?

zzz ok then

zzz 1) naming

eyedeekay Just to clarify by this I mean human-readable naming of the type we use in the addressbook

zzz what about it?

eyedeekay I would like to look into common ways of extending this system, I went through some of my existing experiments with naming and came up with some ideas

zzz what are your goals?

eyedeekay I would like to: reduce dependency on registrars and subscription providers for distributing names, set expectations for the properties of host with the top-level host as shorthand, not conflict with existing namespace, possible implement compatibility with TLS

dr|z3d ri compression, that's yours, zzz :)

eyedeekay Or at least something like compatibility with TLS

dr|z3d (3)

eyedeekay I have 3 big ideas, one-sentence summaries are:

eyedeekay X-I2P-Hostname header

eyedeekay Federated jump registrars

eyedeekay and GNS over I2P

eyedeekay From easiest to hardest

zzz x-i2p header is the analog to tor, for clearnet-to-i2p conversion?

eyedeekay Sort of, we have X-I2P-Location now, which redirects you to a b32

eyedeekay But X-I2P-Hostname would distribute the hostname from the host itself in the form of an addresshelper inside of a header

eyedeekay Which we would respond to with an interstitial offering to add the hostname

eyedeekay I see 3 obvious problems with this one, which I believe I can overcome

eyedeekay I do consider it a goal to be backward-compatible with the existing namesystem.

eyedeekay The easiest way to shortcut that with that would be to give any new system it it's own top-level namespace, `.iip` or `.host2p` for instance

eyedeekay The obvious issue I could see is that there's no collision-protection from the server, clients presumably have to ask the user to disambiguate conflicting hostnames via an interstitial, which is not ideal, but using a different namespace like `.host2p` would prevent it interfering with the existing top-level namespace.The other issue I could see is with TLS, obviously we can't see the headers until they hit the brow

eyedeekay LS certificate itself I think, so if it is valid for both the b32 and the hostname then we could see that and use it in a similar way to the header. Also I have the space to add this to I2PIPB's TLS handler which currently only says "This certificate is self signed for whatever hostname, certificates in I2P are experimental."The last issue I anticipate is that there is no way of associating a 3rd-level hostname with

eyedeekay in this model. This would require "registrars" to reject 3rd-level registration attempts, unless we added some means of signing the header content with the second-level key and had registrars interpret that. It seems achievable but I have not specified any proposed way to do it yet.I suspect that one is the real blocker^?

eyedeekay Sorry, I'll break that back up

eyedeekay The obvious issue I could see is that there's no collision-protection from the server, clients presumably have to ask the user to disambiguate conflicting hostnames via an interstitial, which is not ideal, but using a different namespace like `.host2p` would prevent it interfering with the existing top-level namespace.

eyedeekay The other issue I could see is with TLS, obviously we can't see the headers until they hit the browser, but we can see the TLS certificate itself I think, so if it is valid for both the b32 and the hostname then we could see that and use it in a similar way to the header. Also I have the space to add this to I2PIPB's TLS handler which currently only says "This certificate is self signed for whatever hostname, certif

eyedeekay ental."

eyedeekay The last issue I anticipate is that there is no way of associating a 3rd-level hostname with a second-level hostname in this model. This would require "registrars" to reject 3rd-level registration attempts, unless we added some means of signing the header content with the second-level key and had registrars interpret that. It seems achievable but I have not specified any proposed way to do it yet.

eyedeekay From my notes directly, sorry about that first one

eyedeekay Other things I was thinking: it may also need a warning/general guideline that it should not be used for sites which do not wish to be public, since anyone with the b32 could register the hostname. The interstitial would require a "Reject permanently for this site" option for the clients to avoid unwanted interstitials.

eyedeekay It seems not-crazy to me, and would be a tiny proposal compared to the other two

zzz think I've said it before, but with any naming scheme you have to start with the trust model/architecture. thats the hard part

dr|z3d added complexity for what gain? not entirely clear what we're winning.

zzz the tech is relatively straightforward

zzz yeah I'm having trouble mapping any of the three ideas to the goals

eyedeekay Yeah this is far and away the easiest of the three things I attempted at some point in the past that worked

eyedeekay The one this maps onto is reduced reliance on registrars and jump services, it gives hosts a way to hand out their own names

dr|z3d host header, good idea, but without conflict resolution it's dead in the water.

eyedeekay That's the #1 problem with it but isn't that something clients can handle already?

eyedeekay If I attempt to register idk.i2p to a different key with an addresshelper I get a disambiguation page

zzz we have all the conflict resolution in the addresshelper insterstitial

dr|z3d if you're handing that back to the client, then that's fine. it sounded like you might be bypassing that altogether with the embedded helper.

eyedeekay No never. interstitial-only

eyedeekay It would need a reject permanently button for that reason too, don't want to re-present the interstitial if somebody wants to permanently reject it

dr|z3d sounds like there doesn't need to be another interstitial then, just a direct handoff to the client.

eyedeekay Not a new one, just a trigger

eyedeekay This is the really-easy one, so easy I wondered when I was thinking about it why no one had tried it before

eyedeekay Unless there's an existing thread somewhere I missed

dr|z3d the only thing that's possibly desirable is a note in the client addresshelper page to indicate that the host is providing the addresshelper.

eyedeekay I agree, I think that's a good idea, in fact I was considering whether indicating it in the name itself might be a good idea

zzz why don't you spend 5 minutes on each of the other two ideas

eyedeekay Less easy, maybe the "worst of all worlds," maybe not, would be to have "Federations" of jump service/registrars which communicate with eachother under certain circumstances.

eyedeekay This one's more complicated in a lot of ways one of which being that it may require buy-in from registrars and agreement on communication tools.

eyedeekay And it's less good because it doesn't really reduce reliance on jump servers, it just defines rules for them

zzz we used to do this. you just subscribe to each other. no tools required

eyedeekay It does have the advantage of building a server-side method of disambiguation

dr|z3d I was about to say the same thing, zzz.

eyedeekay Yeah I know, I'm getting to the interesting bit

zzz i believe notbob subscribes to stats

dr|z3d we already have that in part. i2pjump subscribes to notbob, notbob subscribes to stats and reg. there's your federation :)

eyedeekay In this case, each registrar would be able to answer requests to 2 versions of an I2P hostname, one ending with `.iip` and one ending with `.rc.fed2p` where `rc` is a codename that the registrar agrees on using with the rest of the federation.

eyedeekay When answering `.iip` requests you answer with a list of `rc.fed2p` requests, where everybody in the federation answers with the name they have for the service if they have one.

eyedeekay This is to help handle potential collisions on the client *and* server side and participate in finding and preventing attempts to "Poison" hostnames by registering them with jump services before they synchronize.

eyedeekay Attacks of the type described in this paper: tandfonline.com/doi/full/10.1080/21642583.2017.1331770

eyedeekay Protection would work at 2 layers, the clients would receive an(albeit large) bundle of addresses for any given hostname, which could only be accepted if they all agree on what keys the hostname should use.

eyedeekay The server software would also inform all admins in the federation of any conflicting registrations through their admin panel and their source, to provide them with the information necessary to identify and disambiguate conflicting registrations with other admins.

eyedeekay The downsides are also complicated I think, they're very human-factor type things.

eyedeekay It makes a hypothetical jump-federation quite powerful for potentially censoring certain names, but subscription providers, jump services, registrars all already are pretty powerful.

eyedeekay But maybe this could be done in such a way that it encourages transparency.

eyedeekay That said, this is my least-favorite of all three.

zzz that's an awful lot to deal with poisoning which we haven't seen as a problem and wasn't among your goals

eyedeekay Yeah I'm not going to die on this hill, it was just an interesting one from my archive

zzz also any new TLD like .iip isn't great. Better to just use .i2p and 'stack' naming systems. try new one first, then fallback to what we have now

zzz ok there's your 5 minutes, what's your pitch for GNS?

eyedeekay This is the one I know the least about from practical experience so far

eyedeekay There are a few things that have changed about GNS since the last time there was an extended discussion of it on `zzz.i2p`

eyedeekay For one thing, it has documentation now, part of which clarifies that it's not actually tied to any specific storage or communication backend. lsd.gnunet.org/lsd0001

zzz i tried coding it a couple years back and got stuck

zzz in the crypto. don't remember why

eyedeekay Well in this case, the approach *could* be mostly about working with en existing GNS implementation, which would simplify things.

zzz the thing about GNS is it's actually very radical and hard to present to users

eyedeekay I could make this about creating binding-generators for the GNS implementation in go-gnunet, which is quite tiny

zzz there is ****no**** root. everybody is their own root

eyedeekay This would end up as a plugin which would work over SAM

eyedeekay Yes I'm aware, which I don't like, it means we have our own complicated versions of some of the problems from that spec I think

zzz so there would be a idk.zzz.i2p, and a idk.drzed.i2p. depends who your root is

zzz we have a facility for plugging in naming systems on top of what we have now

eyedeekay But I do like that we get to sign our own roots

dr|z3d sorry, network glitch, I must have missed a chunk of discussion.

eyedeekay not that much

eyedeekay (02:58:44 PM) eyedeekay: I could make this about creating binding-generators for the GNS implementation in go-gnunet, which is quite tiny

eyedeekay (02:58:54 PM) zzz: there is ****no**** root. everybody is their own root

zzz so I think we have all the infrastructure anybody needs for experimentation

eyedeekay (02:59:03 PM) eyedeekay: This would end up as a plugin which would work over SAM

eyedeekay (02:59:27 PM) eyedeekay: Yes I'm aware, which I don't like, it means we have our own complicated versions of some of the problems from that spec I think

eyedeekay (02:59:33 PM) dr|z3d [user@zhxsnsdpzpfy2l4w6gzvwlwzcalff3od7ushw3mvjcedrtogvbgq.b32.i2p] entered the room.

eyedeekay (02:59:33 PM) mode (+v dr|z3d) by ChanServ

eyedeekay (02:59:33 PM) zzz: so there would be a idk.zzz.i2p, and a idk.drzed.i2p. depends who your root is

eyedeekay (03:00:20 PM) zzz: we have a facility for plugging in naming systems on top of what we have now

eyedeekay (03:00:20 PM) eyedeekay: But I do like that we get to sign our own roots

eyedeekay (03:00:24 PM) dr|z3d: sorry, network glitch, I must have missed a chunk of discussion.

dr|z3d thanks

eyedeekay I agree, in that way it's could also be less work than the federation thing

dr|z3d my last comments before I dropped off:

dr|z3d <dr|z3d> I'm still not seeing what problem this is meant to solve.

dr|z3d <dr|z3d> I mean, do we actually have a problem right now or is this all hypothetical?

eyedeekay It's not as simple as the header thing and there's this added difficulty of storing and communicating the names

zzz start with the trust model and how any possible solution meets the goals.

eyedeekay This is all hypothetical, it's just a thing I'm interested in and zzz asked for ideas for proposals last week, striking the iron while it's hot

dr|z3d ok

zzz I actually haven't seen very many complaints about the current system. people think they want distributed but what they really like and understand is centralized

zzz half hour in, good discussion, can we wrap it up?

zzz next steps?

eyedeekay Sure

zzz anything else on 1) ?

eyedeekay I'm going to add the hostname thing to sam-forwarder and eephttpd just to play with it, it's about a half-hour's work if that

eyedeekay the GNS implementation in go-gnunet is tiny, I can assess how to make it talk to I2P this week too

eyedeekay EOT

dr|z3d 2) is the RI compression you're working on, zzz? prop 161?

zzz SAM seems like the wrong place architetcurally but as good a place as any for experiments

eyedeekay yeah sam-forwarder is basically an i2ptunnel emulator

eyedeekay For experiments

eyedeekay I do all kind of weird stuff with it

dr|z3d address helper headers gets some interest from me, the other proposals not so much.

zzz if you want to try a stacked naming service in java I can walk you through how to hook it in

eyedeekay Absolutely, would need that for GNS which I want to at least take a stab at

zzz ok

zzz 2) prop. 161 draft

zzz draft is up

zzz i2p-projekt.i2p/spec/proposals/161

zzz I basically wrote up what was in the zzz.i2p thread.

zzz I added a section for future protocol changes as orignal described in that thread, for him to contribute to

zzz not asking for comments today

zzz please review and we can talk about next week

zzz yes 3) ri compression == 2) prop 161

dr|z3d ok, thought so.

zzz orignal last week or two said he didn't see much if any benefit, so I tried to put as much info in there as I could

zzz on where the benefit is and how much

zzz anything else on 2) ?

dr|z3d good work, looks substantial.

orignal yes

orignal so what's the benefit?

dr|z3d i2p-projekt.i2p/spec/proposals/161 <-- orignal

orignal will check

zzz please read the proposal, there's a bullet list in the goals, and an 'estimated savings' section

zzz thanks

orignal "Eliminate requirement to generate ElGamal keypair for Destinations"

orignal huh?

orignal don't we use random ?

zzz see 1st paragraph in overview

zzz the spec doesn't say that

zzz we still generate keypairs

zzz so the first part of the proposal is 'it's ok to use random'

dr|z3d he's quoting the first line of the Goals section.

eyedeekay ~82% of destination and 74% of router identity seems like quite a substantial savings over a lot of requests

orignal so, you proposal is basically compression

zzz y'all please take your time and come back in a week. skimming and commenting in two minutes isn't productive for anybody

orignal I would prefer to replace 256 bytes by 32 bytes

orignal then let me tell my proposal

zzz please write it up and I'll add it to 161. there's a section there for you 'protocol changes'

orignal 32 bytes encryption key 32 bytes signing key and no cert

orignal identity is always 64 bytes

orignal but I have this proposal for many years

zzz write it down how it would work and I'll add it to the 'protocol changes' section

zzz that section is for you

orignal I need to think more how to differentiate old and new

zzz ok

zzz anything else on 2) ?

orignal my another proposal was to always use B33 for destinations

orignal e.g. 35 bytes

zzz there's a bullet list in there of compatibility issues to think about

zzz anything else for the meeting?

orignal I could never understand the idea of full base64 for destinations

eyedeekay Nothing else from me

orignal because we need signature key/type only

zzz all goes back to 2003, before my time, before sigtypes, before b32

orignal I know but it's time to simplify