eepSites - forum.i2p ~ View topic

Guest

I know it's not really a problem, having those long-dead names in there.

But it bugs me.

I've got 837 in my router now, and if tino / perv.i2p are to be believed, only around forty resolve to eepsites, with a couple on top of that for syndie/irc/etc...

Now, is there any way to cut out dead hosts from hosts.txt size, whilst at the same time keeping my subscriptions?

Or will I have to cancel the subs and just add keys manually?

Currently, destination keys are forever, because of the paranoid view on key and host name ownership, and there is no policy in-place as far as any ability to revoke a key or a destination.

I2host may in the future flag these deadwood hosts and have a way to optionally not include them.

The problem isn't really with actual key revocation, the issue is along the lines of paranoia, and possible host name hijacks...

Basically, the name to key is something more of a convenience, and a human way to remember a 500+ character key with a memorable name, just like on the regular Internet. Nobody really actually controls host names on i2p though, and you could scrape away all the dead keys and only add in anything new via i2host now.

However be aware that the names AND keys are forever used, and unless some sort of new policy comes into play, there will be no way to remove one. I have been considering the possibility of having key and host name "owners" self-sign the information, as that would allow verification of actions on the specific key, and also allow a method of verification that the particular key is real, and not hijacked.

However changes like that are fairly far off into the distant future and still need to be discussed with the devs. Currently i2host is only a host name to key mapping distribution method that is a lot more effective than the current sloppy way, while maintaining as much compatibility as possible. Revoking a key would be a tricky business anyway... what if one of these people come back on the scene in a few years, expecting that the key is still there, and still valid? I2host may be able to address this issue as well in the future, by stripping out any host that has not checked in after several months, or some other metric... but once checked in would be able to revive that key... the host name and key, however would still be forever dead, unless specifically revoked by the host name and key owner. perhaps a "deadwood" key like this could redirect you to one of the archiving sites that are similar to the wayback machine... who knows.

Cool

##Sponge.

Hi!

First: Key infrastructure is needed before adding signing key support to hosts. We will need to create a key on every i2p install before we set the option to "hosts.txt entry needs to be key signed" - just to keep it as simple and fast as it is.
Second: we need a tool to create as many keys as we want, for EVERY hostname one key! maybe we can add support for one key=10 hosts, but in normal way, one I2P user who runs 10 hosts doesnCB4t wants to be credited for all 10 hosts - he wants to hide he runs them.

And for conversion: We need a system which keeps out old, unused hosts and holds old, now unused but to be reactivated soon, hosts.
Maybe hashcash for creating hosts? the longer it is "valid although unreachable", the more it is payed via hashcash?
But thats far to complicated, to (at least to implement the tests to it).

For deleting ols, unused entries: I suggest to delete all 1/2 year unused hosts on default.
Yes, we need to set a time value, which is kinda guessed.
BUT we should keep a "donCB4t touch this hosts EVER" list for vital hosts.
Which hosts to set on this list needs to be decided by dev team, I suggest at least jrandom hosts and forum,postman,... you know what I think of.

And for transition: We need to decide and set a docu out and make this change public at least 6 month BEFORE we delete old hosts!

And after we deleted the hosts, we should keep them on hold for at least 1.5 more years, IF the owner comes back AND make clear, he his the owner and wants to reuse it.

In the end, some more database to be created and used.
Just for keep the hosts.txt small
IMHO concentrate on change addressbook protocol to just transfer changes to last hosts.txt to keep traffic low, but as long as I2P doesnCB4t reach the 10k eepsites/hosts, we can use the old scheme.

(it is <5MB still, small enough to be kept this way)

BUT if sponge wants to make some dev in this direction, its fine, but IMHO he has to consider my points.

echelon

I think that if you are willing to sign it, and put in that additional effort, that less people who are unwilling to have a signed permanent trusted site can be placed into an "untrusted" group of mappings until they decide to become a more permanent part of the i2p community.

Think of them as "trusted" v.s. "untrusted", and the ability to sign up for the untrusted keys if you have chosen to do so, and if that site disappears, it can be automatically removed and reused without any human intervention. In order for that to actually work, susidns will have to have a way to remove and change keys, etc... I'm no java programmer, so someone who is, would have to step up and provide such changes, and the devs would need to approve them. I2host in it's self is NOT in java, but implemented in common lisp. Others have considered trying other languages, and the fruits of that have yet to be seen.

There are advantages to having it done this way:

1: A more trustworthy community of sites, where you know that the site is going to be there.

2: A place for temporary disposable sites, which can be revoked.

3: A category for people who are "just checking it out" and don't ever return. This falls into untrusted category, the catchall!

4: The ability to change your key if you lost it in a hard disk crash, because you were a total idiot and never made a backup. Just remember your passphrase.

5: Trusted sites can be polled, and if determined that they are dead (one month should be reasonable) the name and key are put into a limbo status, and can be restored once the site comes back up. There is protection from catastrophe, so that once/if it does come back, you go to advantage point number 4! Smile

While in limbo, the name AND key are still protected, for, say, one year.

6: i2host does check pointing of the data, keys would enable verification. The current method (often referred to as a bandage by the devs!) provides NO check pointing and essentially trusting the headers in the web server. That could become a problem and provide attack angles, and worse yet, you have to trust something unsigned by an unknown party, meaning that hijacks are entirely possible! Sign up to the wrong eepsite on accident, and well, your keys are pwned!

If you really have any thoughts on disadvantages, I'm interested in reading about them. I'm certain I have, or can come up with some sort of answer.

Cool

##Sponge

I2Phile Joined: 10 May 2005 Posts: 311

ignoring the whole signing/revocation debate above...

Guest

Although the debate is interesting, thankyou, zzz, for cutting to the chase. Very Happy

I did think that any deletions would just be replaced, but I didn't know if there was a workaround. I'll probably end up managing my addressbook manually now - my OCD is bad enough that it seems worthwhile. Smile

I2Phile Joined: 10 May 2005 Posts: 311

you can also try http://i2host.i2p/.

I2host can give you key sets in any time frame, including custom ones in as fine as one hour increments if you want to.

The subscription url for that would be:
http://i2host.i2p/cgi-bin/i2hostlast
Which will give you a default 24 hour listing.
You can specify other increments like this:
http://i2host.i2p/cgi-bin/i2hostlast?72
Where the number is how many hours from one to as many as you would like.
This example pulls out the last hosts entered into the database for 72 hours (obviously).

There are more dodads and toys there, stop by, have a look.
Cool

Joined: 15 May 2008 Posts: 14 Location: Berlin

I think, we need to get rid of old, unused names.
Otherwise I could register a whole lot of interesting sounding addresses and not offer anything at all. Just to bother you all a little.
Someone could even try to register almost all names one could easily remember - thus hampering i2p a lot with these 'blocked' addresses.

On the other hand: If we have two or three centralized points that give us the subscriptions and with them even a DeleteName-command, then this could lead to an attack with all names being deleted in hosts.txt.

Even the sites that try to keep track of eepstites that are up, could be under evil control.
So why not let people find out on their own, which site is up and which one no longer exists?
What about not deleting any eepsite's name on a central place like the ones you get your updates from.

It could be considered to rather give any eepsite a specific lifetime - let's say six months.
This sould be done on the client's side.
A new site is entered into my hosts.txt and gets its expiry date which is the date it was entered to my hosts.txt + 6 months.
Now, everytime I visit this site suceessfully, the site's expiry date will be reset to the date of last successful visit (to current date of today) + 6 months.
Thus sites I - and not another centralized place - keep track of by simply accessing them, will be kept in my hosts.txt, as long as they are available and as long as they're of interest.
If they're down for a week - no problem, therefore the 6 months.

Now I might get a link to some other site I haven't yet visited before but someone told me about this site. In order to have it in my hosts.txt I'll need a subscription, sure.
But why not get hosts.txt's from connected peers instead of a centralized place?
The update would simply be: adding the information not present in my current hosts.txt and sending out the amended list.
One could argue that this would raise anonymity problems, as to what sites I have been going to.
But since the hosts.txt I send out is already upddated with the ones my peers sent me, actually no one knows which of the site I have visited and which ones not.
Therefore the lines should be reordered so that it's not my visited sites first, and amended ones in the end (maybe alphabetically, maybe some other order).

Thus sites that nobody ever visits or that are always offline, wouldn't be in the hosts.txt any longer, and at the same time no adversary could bring all eepsites down as there is no central place where he could send out a 'delete-all' command.
New sites are announced (the fast way) through the forum or IRC or (the slow method) by just visiting my new eepsites myself and waiting until my hosts.txt's info propagates.

But I don't know how to handle it if there are two contradictory entries...
But even for this there should be an easy solution like a disambiguising screen in my browser and a personal preference in case there are two different destinations to a given name in my hosts.txt - but I would forward them all, so nobody sees my pref.

What do you think?
_________________
Andy

Joined: 15 May 2008 Posts: 14 Location: Berlin

I still think, the client side approach is not such a bad idea.
If it was just the signing, I could still sign an eepsite and really have it running for a year or so, but finally my PC crashes and I have no backup - there are always people who know they should have backuped but did not.
So again, the not wokring siute's name would be lost forever.
Now if an eepsite is not available because of the owner's firewall setting, then this is, IMMHO, the responsibility of that eepsite's owner and a problem only he has to solve and not one, the community should pay the price for.
6 months is a long time. If I announce an eepsite and maybe have a counter on that site or so, and see that nobody has been on my site for months, I'm getting curious about the why? Boring site? I improve it. Not reachable? I make it reachable.
In case the six months are over and the eepsite is still not reachable, it seems as if the owner had not much of interest in it nor the visitors - other wise they would have complained. So no problem if it drops out of hosts.txt thus making the name available again.
In case the old owner finally fixes his site, he can get back the name if it's not taken already.
Maybe there could be some grace time in which the name was not yet deleted from hosts.txt but only marked as disabled. (maybe, maybe not)

In order to dispersew fears that thus eepsite's owners could change too easily without anybody taking notice (Let's say a site I trust becomes controled by an adversary that makes the site still look all the same) the site and every change on it could still be signed.
But I'm against these static for ever existing sites without any content.
If the site is reachable and has content (i.e. it is of somebody's interest - and only then it's useful), it will stay the same forever.
Eepsite owner are not only responsible for their content but also for their reachability.
So why should I have eepsites in my list and their names blocked for further use if they will have been down for twenty years, just because someone once signed them?
Still, signing should only authenticate the content, but not determine the lifetime of the names of eepsites that are down.
_________________
Andy

I2Pothead Joined: 13 Apr 2005 Posts: 121 Location: de

My 2 cents:

Why not publish an official "dead keys and revocation" deadhosts.txt file and re-program SUSIdns such, that it is able to read this file and kill such dead keys from hosts.txt (if the complete line matches)? This file could be signed with some I2P developer key (or some other maintainer key).

If you want to get rid of those dead keys, you can download the last version now and then (manual process!), check the signature (GPG) and give it SUSIdns to kill those destinations automagically.

All needed is:

- Support of SUSIdns to support a signed "negative list".
- Publishing this "negative list" somewhere well known.

The "negative list" is just a deadhosts.txt and a deadhosts.txt.sig.

Note that I *will* support such a model in my inProxy, too.

However it musts be easy and convenient, such that it can be utilized with just a few rough hacked shell lines from outside I2P (or Java, or ..).

Therefor I *cannot* support "signed revocations", "hosts.txt expiry after some time" nor any other complex model. A signed official distribution of just a single file should be enough.

Note about security:

If some evil one manages to publish a compromized deadhosts.txt, this is easy to detect. For example my inProxy can hand out an alert then.

Listing a destination in deadhost.txt is listing the destination, so you do not suppress any information! All you can do to hide this entry is to have zillions of other destinations for the same name, but this can be spotted easily.

(Perhaps I can add a "yearly" task, which checks a dead destination now and then, such that there is a note when it comes back.)

Side-Notes:

If a dead key shows up several times under different names it will need several revocations. So only the exact "name and key" combination must be erased. And as it is an easy to see text file, there is nothing hidden, which is good.

Also note, that everybody can create a deadhosts.txt and publish it. All you need is to trust the signature of this file, then.

The deadhosts.txt file should be sorted alphabetically, except for the intro header (lines starting with semicolon) which is skipped.

The deadhosts.txt file is invalid without a proper deadhosts.txt.sig file nearby. And there shall be only one single well known name to it.

Last thoughts:

This way we can temporarily switch to another www.i2p (as www.i2p.to is down, sadly. No I do not hack something myself. I just follow if the path is easy enough) until www.i2p comes back (hopefully).
_________________
-Tino
About my fproxy see http://tino.i2p/freenet.html
About my inproxy see http://i2p.to/
Alternative Seed URL http://i2pdb.tin0.de/netDb/

1: The idea of having a signed key prevents the whole "evil empire takeover" issue.
2: Signed keys also will have an expiration date, which is 1 year plus some grace time.
3: Keys should be sorted by time entered, so that trimming makes sense.

I2Pothead Joined: 13 Apr 2005 Posts: 121 Location: de