Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[Martin Dobrev]

On 07/02/2019 08:02, robots.txt fan wrote:
> On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher <address@hidden> 
> wrote:
>> Because you can reject a key, but then what happens is it just keeps trying 
>> to come back. Pretty soon there are so many rejected keys floating around 
>> that the network stops reconciling. Also, what happens if I reject certain 
>> keys and you don’t, but your only connection to the rest of the network is 
>> through me? Once nodes start implementing different policies you can go 
>> split-brain surprisingly easily.
> I shouldn't have written "reject". If you already have this key in your 
> blacklist, just tell the other keyserver that you already have it, but do not 
> store it. Store only the hash.
>
> Of course it might still be possible to code information into the hashes like 
> Tobias wrote, but at least generating exactly the right hash is extremely 
> expensive (if not impossible) from the attacker's perspective so I do not 
> think it is feasible for them at all. Storing hashes of kryptonite should be 
> okay.

My idea for blacklists is in a sense similar - during recon process
consolidate hashes from the blacklists with whatever is in the live
database and report this to peers. This way it won't trigger continuous
*recon/fetch/drop due to blacklist* loops. There is only the risk that
downstream servers that don't use blacklists will keep asking not just
for the hash but the key too. This is something that can be mitigated in
the next-gen gossip protocol: server A asks for a key belonging to a
hash, it gets a response that server B is not actually having it due to
blacklist flag. Server A can ask another member from the membership pool
to provide the key. If all peers flag it as blacklisted set a flag and
give up retries until membership file changes.

Is this going to work? Most probably yes. Is it going to cause some
issues (see above) due to backwards compatibility in the short term -
yes, but then operators will be keen to upgrade to next-gen server
implementation and the problem gets solved in the long run.

>> It’s not a simple matter of just coding it up.
> Of course not, and I wouldn't dare claiming that. I agree with Martin in that 
> I also am glad to see that there is a will to invest time in developing a new 
> server. The Synchronising Key Servers should not vanish from earth.
>
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel