Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher 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. > 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 Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
Robert, No doubt it's risky to implement things that there is no consensus on. But the device I'm writing this on was invented by *not a consensus*, and a consensus to design it would not have emerged on this list nor elsewhere. The risk may be lowered: 1) on behalf of our company I'm excited to run whatever not-sks testnode you prototype 2) fwiw there's Hockeypuck written in a popular language and popular db. The sks recon is separated into a module, and could be swapped out. All the other bells and whistles of a ks are there. 3) find one more person and we can call it a test network As an alternative to Hockeypuck, we also use a keyserver on the backend written in Node/TypeScript and postgres that I'd be happy to strip/clean up and contribute. It has no sync nor consensus built in. Based on OpenPGP.js. I wrote it purely out of my frustration with sks. I think this list needs resolute action, not consensus. Resolute action is risky, sure. My company will issue a modest grant to get a ball rolling on whatever is not-sks, implemented by a person with a brain (you're overqualified!). Cheers, Tom On Thu, 7 Feb 2019, 08:46 Robert J. Hansen > It is no use to wait a great consensus. > > Without exception, I have never met someone who was reluctant to > volunteer someone else's time. I think this is unfortunate. I'd rather > we were as reluctant to urge other people to commit their time and > effort to a project as we are to commit our own. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 07/02/2019 08:02, robots.txt fan wrote: > On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher > 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 > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Quick and dirty test
Todd Fleisher dijo [Wed, Feb 06, 2019 at 08:24:38PM -0800]: > FYI - that site generates an untrusted ssl certificate warning and > after acknowledging that I get an error that the site couldn't be > found on dreamboat. You are right, I will now check with Dreamhost why this is happening. Try the same URL, but without SSL: http://sks-status.gwolf.org/ I will soon add some more explanation, the source to my program and more. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2019/02/07 05:35, Gabor Kiss wrote: > And all these programs can talk each to other due to RFC 821 (1982). Well, yes. A good protocol is everything. The implementation is relatively easy. Ensuring that the protocol doesn't result in a cascade failure is the Really Hard Problem. We're still trying to mitigate the unintended side-effects of RFC821, 37 years after the fact... :-) A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2019/02/07 11:01, Martin Dobrev wrote: > 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. I wrote a doorstop post on blacklist mechanisms some time back on this list. The implementation planning is a rabbit-hole, and that's before you even start thinking about higher-level problems like split-brain. Eventual consistency is a harsh mistress. :-) A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2019/02/06 23:51, Robert J. Hansen wrote: > No. Keyserver reconciliation is 90% of the problem. Fixing this would > make it impossible for older keyservers to reconcile with a next-gen design. I have had a long think about this problem, and I reckon that the biggest bar to progress is the assumption that arbitrary members of the pool will upgrade to the new software at random, and that we need to ensure that all nodes stay synchronised with each other no matter what version they run, in a single mixed-version network. We can simplify this problem considerably. Instead of an operator upgrading their sks server to "new-sks" and expecting to still be able to peer with traditional sks servers, they should install the "new-sks" software *in parallel* with the traditional one (on the same or a different machine, doesn't matter) and this "new-sks" node should only be able to peer with other "new-sks" nodes. This means that our new recon protocol can be efficient, because it doesn't have to keep a record of blacklisted hashes. If we further assume that key material does not flow back from the "new-sks" network to the old one, then we can write a relatively simple cron job that finds updated keys on an old-style sks server (by parsing its logs, for example) and copies them (suitably censored) to the corresponding "new-sks" server. At some point, when the "new-sks" network is sufficiently stable, the pools are redefined and the old sks network becomes irrelevant. The above allows us to ignore broad categories of problematic material by policy, simply by defining a narrow set of allowed packets in the new protocol. Any compliant "new-sks" server will simply not be capable of processing packets of unapproved types, e.g. image IDs, 3rd party signatures, and keys with invalid self-sigs. Also, any peer that tries to serve too many unapproved packets via recon can be twitted. What the above will not do is allow individual operators to blacklist arbitrary packets by hash, not without either some central authority defining a shared blacklist, or a fake-recon process that maintains local blacklist caches and runs the risk of split-brain. So the threat of shutdown by court order is not completely removed. I still think this may be enough to be getting started with. A signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2/6/19 8:28 PM, Robert J. Hansen wrote: > What we don't have is *consensus* -- not only among ourselves, but in > the larger community. The current discussions we're having (e.g during OpenPGP email summit in brussels in october and lately on FOSDEM last weekend) is eventually not storing UIDs at all on the keyservers, but require the user to do key discovery through WKD, directly on a website or the like. This still allows using keyservers to distribute revocation certificates and updates to subkeys etc, but not as a discovery mechanism. Pool-wise it'd be setting up a separate keyserver network that will gossip with the existing network for a time, with separate pool for the with-uid and without-uid servers, before the full switch is done... The new network would be running on software replacing SKS, using more suited database backend that and multi-threaded implementation. The current disagreement are really with regards to whether this should be "validating keyservers" or not, and how such servers could interact with non-validating ones. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A committee is a group that keeps minutes and loses hours." (Milton Berle) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Shutting down keyserver.pch.net
For reasons of internal capacity and infrastructure re-engineering, we are shutting down keyserver.pch.net. We do want to continue to participate in the keyserver community, and hope to bring our service back online again in the next few months. Thanks to all our peers, and fellow keyserver operators for your support. We'll send a note out to the list once we're operational again to get re-peered. Ashwin signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
