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
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