shutting down SKS on zimmermann.mayfirst.org

[Daniel Kahn Gillmor]

given the issues with the SKS keyserver network, and how MF/PL is moving away from relying on keys.mayfirst.org for its own internal use, i propose shutting down the SKS instance running on zimmermann.mayfirst.org.

This means keys.mayfirst.org will go away, and there will be one fewer server in the SKS pool. It will affect everyone who has keys.mayfirst.org listed as their default keyserver.

Some things to do for this shutdown to happen responsibly:

• think about what to do with requests that still come in. should we provide an HTTP 301 redirection to the HKP interface on a well-managed, constrained, abuse-resistant keyserver instance like hkps://keys.openpgp.org That could probably be implemented with an nginx or apache configuration snippet. Alternately, we could configure nginx to act as a reverse proxy and cache to an abuse-resistant keystore. Other ideas?
• send mail to sks-devel announcing the plan
• mail the SKS peers of zimmermann individually to let them know that they should de-peer it
• announce it in some more formal way; I don't really know how to manage such an announcement, and would love help planning and publicizing it.

[JaimeV]

I like the idea of the nginx reverse proxy or the redirect if this will save some people from abruptly having their workflow or automatic key updates break.

I can help with drafting an announcement. Do we expect any kind of reaction from sks-devel or SKS peers if/when do this?.

[Jamie McClelland]

Thanks dkg for starting this ticket. I got the notice on IRC - but you can also cc: me so I get a notice via email which is the most reliable way to alert me to a ticket.

I think the http permanent redrect would be the best option, since I don't think we should plan to keep keys.mayfirst.org alive forever and it sends a signal that any client connecting should know that this change is considered permanent. I'm not sure how many humans will actually get that signal, but it still seems like the most techically correct approach.

I also wonder if we can fashion such a redirect to exclude connections to ​https://keys.mayfirst.org/ (e.g. with no path component), so we could display a page with the announcement on it? Would this interrupt the redirection of a regular request for a key?

Lastly... I'm trying to work on an announcement about this entire situation for the full May First membership, and I think shutting down keys.mayfirst.org could be part of it. Our public announcement about shutting down keys.mayfirst.org could include a link to this more broad announcement to help provide context (or vice versa?)

[Daniel Kahn Gillmor]

Thanks for weighing in here. btw, i'm also fine with making this ticket non-sensitive whenever you all are, because i think it is good for the community to see these deliberations.

jamie, i'm not sure why you think we shouldn't keep keys.mayfirst.org alive forever (before i opened this ticket, i thought indefinite maintenance of keys.mayfirst.org was the plan). can you say more about why you think that keys.mayfirst.org ought to go away? like it or not, MF/PL is a known and relied-upon part of the OpenPGP ecosystem at least in some corners. Do we want to step away from that role?

some thoughts re: reverse proxy vs. 302 redirect:

• if we do the 302 redirect, we'd need to ensure that dirmngr (and other possible keyserver clients) will actually follow such a redirect. i've run into ​weird ​problems with redirects from dirmngr in the past.

• if we do a reverse proxy, we would in some sense be operating as an anonymizing proxy for our users w.r.t. the data available to keys.openpgp.org about its clients. I'm not convinced that that role is hugely meaningful, but it does provide an initial layer of defense against at least some part of the concerns about re-centralization that are represented by keys.openpgp.org.

I think i'm currently leaning toward a reverse proxy at least for the HKPS and ​VKS interfaces, along with an updated "landing" page, but i could certainly be convinced otherwise.

[Daniel Kahn Gillmor]

Note also that keeping hkps://keys.mayfirst.org as an at-least-somewhat-useful (non-redirecting) endpoint suggests an opportunity to participate in (and help shape) ​any future federation that arises from the ashes of SKS.

[JaimeV]

I also like the idea of preserving keys.mayfirst.org as a sign that we still support and promote the use of OpenPGP standard based encryption. Shutting it down now would send the opposite message at a time when some people , especially the non technical sector of the movement may be on the fence about abandoning OpenPGP encryption altogether in their daily use.

There have been some major setbacks for the proliferation of OpenPGP usage for sure. But for all of its problems I don't think we have anything as versatile and widely supported at the moment and I don't think we should abandon it.

I'm also fine with making this ticket public.

[JaimeV]

Replying to Jamie McClelland:

I also wonder if we can fashion such a redirect to exclude connections to ​https://keys.mayfirst.org/ (e.g. with no path component), so we could display a page with the announcement on it? Would this interrupt the redirection of a regular request for a key?

I thought of the same, regardless of whether we are doing the proxy or redirect I think it may be as simple as using a location = / directive in nginx that points to an html page with information about whatever it is we finally decide to do.

We could test the above and the proxy/redirect to keys.openpgp.org with a new domain for now.

Lastly... I'm trying to work on an announcement about this entire situation for the full May First membership

I'd also like to help with this.

[Jamie McClelland]

Sounds like we are all good with making the ticket non-sensitive so I'm making the change.

jamie, i'm not sure why you think we shouldn't keep keys.mayfirst.org alive forever

Now I'm confused! I think, dkg, you are talking about the domain, right?

I read the this in the ticket:

This means keys.mayfirst.org will go away, and there will be one fewer server in the SKS pool. It will affect everyone who has keys.mayfirst.org listed as their default keyserver.

And thought you were proposing that we make keys.mayfirst.org go away permanently.

However, now I think your proposal is a bit more nuanced.

I'm in favor of keeping keys.mayfirst.org if we have some ideas on how it can continue contributing to the ecosystem. My preference for a permanent redirect was based on the assumption that it was going away, not based on a preference for it to go away.

[Daniel Kahn Gillmor]

OK, this discussion has been basically idle, so i think everyone has probably weighed in who cares to weigh in.

I'll start setting up an nginx reverse proxy to keys.openpgp.org on zimmermann.

JaimeV, i'm taking "ownership" of the ticket just because someone needs to do it, but i would not object if you wanted to take it over again! i'm not trying to step on any toes.

[JaimeV]

I've got no toes left in this and no fingers to spare. I really appreciate your help dkg. If we can review the nginx config together when you're ready I can try to be involved in the upkeep.

[JaimeV]

I'd like to take this up again but I have questions about how to proxy between hkps://keys.mayfirst.org and hkps://keys.openpgp.org

[JaimeV]

If ​hkp and hkps are used over http and https respectively then it seems a reverse proxy configuration is possible. I'm not sure what range of request headers we need to proxy and any special headers we should set or ignore to ensure this works.