Matthew Toseland wrote: > On Wednesday 05 March 2008 14:09, David Sowder wrote: > >> Reading through some old threads (catching up on some of the devl@ >> traffic I hadn't read yet), Matthew mentioned something that gave me an >> idea. >> >> Perhaps the seednodes could connect to each other, verifying each other >> as valid seednodes. If there are trust concerns with just anybody's box >> being a seednode because of attackers and such, perhaps there could be >> two tiers of seednode, the first tier would be between only those were >> manually added to the first tier group of seednodes. The second tier >> could be automatically joined and verified by the trusted first tier. >> > > If the first tier is known, the second tier can fake it by always working > when > a first tier node connects to them. And if it's not known, it can be found > out fairly easily. > Same problem the single, centralized checker would have, but yeah, that's true.
I see two possible mitigations: a shadow set of first tier members only known to other first tier seednode members and random opennet nodes doing the check instead of or in addition to the first tier seednodes (multiple checks by multiple nodes should generally agree on the result) (the random opennet nodes may or may not also be second tier seednode members). >> If this two tier seednode pool approach looks good and is implemented, I >> see a potential for the seedserver to merely need to talk to the first >> tier seednodes (to verify they're up ATM) and maintain a roundrobin A >> record list for a hostname such as seeds70.freenetproject.org (this >> layer can potentially have a pretty decent level of redundancy to >> mitigate DoS attacks). Seedclients could then be coded such that they >> merely need to make a connection to one (or more) of the seednodes >> listed in DNS at seeds70.freenetproject.org to get a list of FNP-level >> seednodes (i.e. members of the first and second tier seednodes) to >> connect to be used for announcement. >> > > You haven't solved the first problem (bad second tier seednodes). > What about if it can be solved? >> The first tier seednodes could use a common pool of public/private key >> pairs, the public keys of which would be shipped with the installer. >> The installer has already passed a signature check at this point, so >> either the public keys are good and work on the seednodes listed at >> seeds70.freenetproject.org or the installer has been compromised and the >> public keys aren't good on an uncompromised seeds70.freenetproject.org, >> forcing both the installer mirror network source and the >> seeds70.freenetproject.org source to be compromised to silently >> compromise a seedclient. the installer mirror network and the >> seeds70.freenetproject.org source maintenance could be maintained in >> separate VMs on emu at a minimum and potentially on separate, >> geographically separated systems at the extreme. Both could be >> monitored by a stealth set of parallel operations (private instances of >> the seedserver software, not made public necessarily outside of the core >> devs and/or first tier seednode operators and potentially, private jar >> file build farms, pulling from public SVN/in-Freenet DVCS). If the >> seeds70.freenetproject.org list doesn't change too terribly quickly, the >> list could also be published in Freenet allowing potentially anonymous >> third-party verification. >> >> OK, now you can pick it apart... :) >>
