zzz.i2p

As some request hit me to alter an eepsite destination (which I will decline), I thought about this and possibly found a way how to support altering destinations in hosts.txt from a global perspective.

Let's call the old destination "wrong" and the new destination "right".

To support replacing a wrong destination with the right one we need support for this in two situations:

First, the wrong destination must be removed from hosts.txt.

Second, the addressbook must not re-learn such wrong destinations.

This way hosts.txt would be cleaned from the wrong destination and able to learn a right one.

So, what do we need to remove a wrong destination from hosts.txt?

We need a list, which contains all the wrong (dead, revoked, whatever) destinations. This list must be supported in addressbook, such that this list is read and no destination which is in this list can be learned again. Also all destinations which are in this list and in hosts.txt are removed from hosts.txt (probably by addressbook, too).

Also addressbook can learn this list like it is able to learn hosts.txt. The only difference between hosts.txt and - say - revocations.txt is, that a destination (name) can be listed multiply in the revocation (with different keys), as there can be more than one revocation.

There is a single last question: How are revocations authorized. The answer is the same as with hosts.txt: There is no such authorization. It is learned from sources which you trust like hosts.txt (which initially is: none).

This leads to a last thing: The revocations.txt file should be accompanied with another file, say "protect.txt", which contains some "protected" destinations, which inhibits the revoke of these destinations. This file is NOT updated by addressbook, but is, instead, part of the router distribution. It should be accompanied by a second - manually editable - file named "protect.local.txt", which does the same with manually entered destinations.

Perhaps my proposal seems a little bit weird. However with a proper revocations.txt we could get rid of all those dead destinations in the hosts.txt, so there would be a way to clean up things.

Think of the future. Think when we have thousands of users running routers.

From a security perspective hosts.txt is the right choice, so keep it as it is and DO NOT LET US REPLACE IT BY SOMETHING LIKE A DNS LOOKUP. First hosts.txt should be small (as distributed). Only people who know what they are doing (around 1% or less of the I2P users!) will let the router "learn" new destinations using the addressbook. 99% (or more) will stay with the initial hosts.txt.

The hosts.txt therefor must be populated using some - perhaps to be defined - automated lookup, the first time the user looks up an unknown destination. Not via addresshelper, this is bad, as it is not comfortable enough (one click more is one click too much). So there must be a way to "autolearn destinations on demand". However this will not learn ALL addresses, only the single one which is looked up.

Additionally, most of the eepsite owners will not be able to read documentation (as 99.99% of all Internet users are no more able to read, they are only able to skim through information, but do not take notice of anything else then what they are exactly looking for). So they will clutter the I2P namespace with destinations, which will vanish, because they forgot to save their key before some reinstall (like harddrive failure). Even if they cannot "reclaim" their old name then, still hosts.txt will start to fill up with zillions of unused names.

There must be some automated way to clean this up. For "normal" users (who are not operating any eepsite), this can be done by telling them to completely re-install their router, as this will re-install a clean hosts.txt and re-learn all addresses. For "paranoied" users (and there will be some) we need a better way. This is, to revoke dead destinations (for example which were not seen for over a year) such that they can keep their hosts.txt file (note that these people WILL read documentation and follow it, but only up to exactly the point where they have reached their goal, then they will immediately loose interest and will forget how they have done it. This is normal nowadays. Likewise normal is, that they will trust ANY source which tells them about it, as long as this source does not look fake. This is why phishing works quite well. We, who never will be fooled like this, are NOT THE NORMAL PEOPLE, we are simply freaks, nerds and geeks, period. However I do not want to have I2P only for freaks, nerds and geeks. It must reach the NORMAL people, and it is our task to prepare it for them).

This is where the revocations.txt file comes into play. However we must be prepared to protect live destinations. Else some morons may try to censor some destination using revocations.txt (remember: People do not read. However if you tell them a nice trick to speed up their I2P, they will blindly follow. Even if that trick is to fool them to update their revocations.txt file using addressbook).

The protect.txt file is just there to be able to quickly react on such an attack - just bring out a new router version which is accompanied by the destination under attack using a modified protect.txt file. As people then will blindly follow update protocol, as Microsoft told them that this is good, you know? (So keep it like Microsoft does: Download the I2P update in the background and install it on the next restart by default. Leave it to geeks like us to disable this feature. Else 99% of the future users will never do updates, as they will never look at the update warning, as they are happy with the eeproxy, which never told them to do updates. "Uh, there is an I2P router console? Looks geeky. Ah, I ignore it, as it works anyway!").

The truly paranoied (those, wo not even trust the I2P developer team. This are the ones, who not even trust their toilet, because somebody might have tapped their waste water lines) can copy their hosts.txt file onto protect.local.txt (or whatever), to disable revocations of any learned destinations.

However it becomes simpler for them, too, as they need not to edit hosts.txt, they can edit their protect.local.txt file. Which is less error prone, as errors in this file does not harm anything as bad as, for example, you loose your hosts.txt file due to some edit error (like the save saved a 0 byte file due to harddrive issues like drive full).

Sorry to stress this (perhaps to stress this again, as it might be a FAQ). However as such a request to change a destination hit me, I think, this will not be the last time, it will become more frequent. Yes, there now is a new FAQ entry in my inProxy for this. However, as I said, people do not read, and that's normal nowadays.

See also:
- http://inproxy.tino.i2p/faq.php#destination
- http://i2p.to/faq.php#destination

-Tino
PS: And if this is a FAQ - well - I am normal then, in that I cannot read, likewise.

Last edited Sun, 26 Apr 2009, 3:19am by tino

Now there is an excellent idea! I too have an additional couple of ideas that has been around for a while and not yet implemented.

Idea #1: Temporary addresses, that last 3 months.
Idea #2: Migration of temporary addresses to permanent after they are seen for 3 months.
Idea #3: Migration of permanent addresses back to temporary after they are not seen for 3 months.

As you see, if someone has an eepsite for 3 months, chances are they will be here at least another 3. And it gives someone 6 months to recover the keys/rebuild a system. If it explodes within the first three, and you lose it, well, that's really your own stupidity for not making a backup, now isn't it?
In short... when a host is gone for 6 months, it's considered dead, and I consider that quite a fair policy. I've been itching to do this very sort of thing in the I2HOST infrastructure.

As far as the jump-links thing... That is where the "DNS-like" thing can come into play... Fetch the address for the human, and store it into a "learned.txt", with a time stamp. Each time a user requests the key for it, you update the time stamp. If user does not request the destination for a month or so, remove it. Perhaps check the timestamps every 12 hours of uptime. I2HOST already supports time stamp concepts, and would be an easy fit for all of the above.

Some ideas for host-add service:
- Prevent adding dead destinations. After new host submission it must be checked for availability. For example, we give 2 days for availability checking after submission, one check every 30 minutes. For successful addition require rule "host must be up and running at least 20% of time".
- Auto-removing hosts after some inactivity period (3 to 6 months for example): may be bad idea, i'm not sure.
- User registration. Allow users to change base64 hashes for their hosts. May be very bad idea.
- Submission log with status detail: "adding in-progress", "adding failed" etc

Comments?

I think revocations.txt 3-6 months is fair

and removal from official hosts.txt after a longer time...

or if there was some reason (agreed on by at least two (more?) code-signers/code-commiters for the official hosts.txt to not include it...

(or as seen fit by the operator of the hosts.txt publishing eepsite... which afik any eepsite can do...)

and as the b32/64 address will still work after it is gone from the official lists, it would be like loosing a webmail account because it's been too long since you logged in, but you could email your friends from your new account, and authenticate with them by content, or other communication channel...

so it would be a bummer if someone else scooped up your cool foo.i2p while you were gone, but you could still be found by those you gave the b32 or b64 to add to their local addressbook or bookmarks depending on geekihness level and paranoia level

checking the newly submitted site is up for some time before adding sounds like a good idea...

(2 cents deposited)

but.. what about the scenario for example of jrandom returning...

if something he hosted were to come back up on the network- (say his eepsite) present state would allow it to work afik, though if it was on the revoked list or gone completely, he'd have other means to authenticate himself to those who might still be around that he knew back when he was here...

Other than scalability when there's lots more users, this could also reclaim i2p.i2p... ?

trust is only local, so as long as the user keeps being the only one who decides whther or not to use the revoke service as well as he chooses whether or not to use hosts.txt subscription and if so which one.
Furthermore I second the idea of a "protected" list that cannot be removed (whether you need two of them or not, is beyond the scope of this post). But even if you chose to receive updates on revokations, you'd still want some names where you can be sure the dest has not changed - for dests are _the_ authentication method in i2p. All the other methods are merely untrusted services. For those also desitributed attempts with p2p propagation over exploratory tunnels seem viable.