💾 Archived View for bbs.geminispace.org › s › Gemini › 1188 captured on 2023-06-16 at 17:01:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
This is a very interesting blog post by curl maintainer Daniel Stenberg. The suggestions he has for the Gemini protocol are summarized below:
* 1. Split the spec into three separate ones: protocol, URL syntax, media type. Expand the protocol parts with more exact syntax descriptions and examples to supplement the English.
* 2. Clarify the client certificate use to be origin based, not host name.
* 3. Drop the TOFU idea, it makes for a too weak security story that does not scale and introduces massive complexities for clients.
* 4. Clarify the UTF-8 encoding requirement for URLs. It is confusing and possibly bringing in a lot of complexity. Simplify?
* 5. Clarify how proxying is actually supposed to work in regards to TLS and secure connections. Maybe drop the proxy idea completely to keep the simplicity.
* 6. Consider a way to re-use connections, even if that means introducing some kind of “chunks” HTTP-style.
In my opinion, 1, 2, and 4, are all very good ideas we should push for. 3 is a tough one with some good arguments both ways, 5 is unnecessary, and 6 is practically a non-starter.
One concerning thought: are these kinds of changes even possible at this point in time? I get the sense they have all been hashed out over and over already.
2023-05-28 · 3 weeks ago · 👍 skyjake, sirwilburthefirst, ghostzero, emilis, tukan, Addison, eph, lufte, flipperzero, benk, ttocsneb, crusom · 1 🤔
I agree with a many of the technical points on TOFU certificates, the URL encoding mess, and proxying. These are all things that I was thinking about when I was designing spartan://
It does bug me though when I see generalizations repeated like "They think...", "They insist that...", etc as if everyone here was one monlithic entity. There is no organizational heirarchy or any kind of community consensus here since the mailing list shutdown and solderpunk went AFK.
Certainly interesting to hear a perspective from someone steeped in the byzantine complexities of web standards. Reading the article, I get the feeling that he has trouble accepting the intentional compromises and limitations of the protocol that have been made in the name of limiting complexity and ease of implementation. "Scaling well" is pretty much an intentional non-goal of Gemini. I do agree that a finalized specification needs fewer ambiguities (e.g., regarding proxies) and further clarifications of edge cases, as he points out, i.e., finishing the work that was ongoing in GitLab.
1. Split the spec into three separate ones
Makes total sense.
2. Clarify the client certificate use to be origin based, not host name.
Client certificate use is based on a complete URL prefix, partial or full path included; I'm not sure if he realized that. This naturally includes the server port number (default port 1965 assumed if not specified).
3. Drop the TOFU idea
TOFU is a reasonable compromise between relying on CAs and having no kind trust mechanism between clients and servers. There has been various improvement ideas discussed in the past, e.g., shared repositories of known trusted fingerprints. I think DANE has a higher chance of getting traction, but it's too complex for clients to implement widely. Also, nothing stops clients from accepting CA-trusted server certificates as well (Lagrange does).
4. Clarify the UTF-8 encoding requirement for URLs.
There were plenty of discussions about this already on the mailing list and in GitLab, too. I think what clients actually do is punycode the domain and percent-encode the UTF-8-encoded URL, making the Gemini request itself 7-bit ASCII.
5. Clarify how proxying is actually supposed to work in regards to TLS and secure connections.
Proxies are a bit of a murky area. When a proxy makes an outgoing request, it acts like an independent client — if you want to fully trust a proxy server, you need to run one yourself and manage its trust store manually. But in practice proxying is mostly done to access non-Gemini URLs. The idea of proxying is very useful/flexible, so dropping it is not attractive.
6. Consider a way to re-use connections
No thanks. I think here the high-performance / optimization mindset shows. Gemini is not intended for making tons of fast requests to download large documents. I think the TLS-level session resumption is a decent compromise for reducing overhead, as it is functionality provided by the SSL library and clients don't have to worry about it too much apart from maintaining some time limits on the sessions to prevent abusive tracking.
are these kinds of changes even possible at this point in time?
Some surely are, but in the end it's up to Solderpunk how much he wants to tighten the specification. I think the spec is "good enough" to use as is; ambiguities tend to resolve themselves out in the wild to some degree as many client/server implementations need to interoperate.
The author may have very good points on the technical side, but (as expected) he don't understand a thing about the ethical principles that are integral part of Gemini. Mentioning scalability when discussing Gemini is fundamentally at odds with the small and decentralized network that already exists (a fact that Stenberg happily ignores). Worries about wasting resources for multiple connections don't seem to take into account the minuscule size of each response.
@skyjake
About 2: Thank you for explaining about client certificates using the complete URL prefix. The spec does say this:
That certificate's fingerprint and expiry date are saved in a persistent database, associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database.
Which should probably be clarified.
If 4. is another divergence between the spec and real life implementation, that's another change due.
As for 5, on second thought I actually agree that the way proxies currently work is fine - you have to trust your proxy, but you don't have to use one. That's acceptable.
@satch
That [server] certificate's fingerprint and expiry date are saved in a persistent database, associated with the server's hostname.
Yeah, the database of trusted server certificates should in practice include ports. This was actually the cause of a bug in an early version of Lagrange. I wasn't keeping track of the port numbers.
I created my own post to address all his points on my capsule, but you all were faster here and I don't think my posts would add anything meaningful to the discussion. 😐
Who said the smol net is slow again?
Apparently, this post is being discussed on hacker news and I'm not sure, if should venture into the circus maximus of technical online discussions.
Thrig.me had a good point for point response to this, had me laughing the entire time.
— thrig.me/blog/2023/05/29/http-client-person-from-gemini.gmi
On Tofu - I'm of two minds. It's actually more work to implement when writing a client, as most libraries consider CA validation to be the "happy path". That said, we're not exactly hosting bank websites over here. TLS is primarily providing transport security, not identity. Our identities are often anonymous in Geminispace. So to me, the point that using Tofu leads to security implications because of weak identity verification is no point at all.
Connection re-use makes not a bit of sense in context of how Gemini is used.
are these kinds of changes even possible at this point in time?
Well, they are, but not without a lot of pain. Not everyone is likely to update to a newer version of the spec at the same time. Some may not do it at all. So you wind up having to support multiple versions in perpetuity if you want to avoid breaking people's things. Personally, I don't want to break people's things and don't see a need to change the spec at this point.
@mozz yes I found Spartan a much nicer spec to implement, both from a server and a client perspective. I wish it was used as much as Gemini is.
2023-05-29 · 3 weeks ago
His opposition to TOFU strikes me as FUD. Nobody is implementing banking apps in Gemini. TOFU is good enough.
@jeang3nie Yes, Thrig.me's response is certainly worth a read. 😃
Maybe we should take this opportunity to finish here the work started on gitlab of finalising the spec? I don't know how well Bubble will work for this kind of discussion, but it's at least more accessible than javascripty gitlab. If we can reach clear reasoned community consensus on the remaining (small) issues, we can hope that Solderpunk would approve and incorporate them into the official spec.
@mbays Gitlab seems deprecated. The spec over there is outdated. Somewhere in the Gemini FAQ points to git://gemini.circumlunar.space/gemini-site
@mbays I think the problem with anyone else but Solderpunk finishing the spec is not with any technical solution, no matter how well-suited. No one but Solderpunk has the authority to do that work.
At best I could see an unofficial community-blessed "amendment" being put forth as a delta on top of the circumlunar specification, purposefully contradicting nothing in the official spec but just tightening things up based on experience from actual server and client implementations. Solderpunk might then at some point be interested in incorporating some of those things into the official specification.
@skyjake Solderpunk has the final say, agreed. This would just be to hash out again exactly what is unclear in the spec and see if there can be some consensus on how it should be clarified.
@stack1 exactly.
2023-05-30 · 2 weeks ago
I replied a messload to this whole thing through so many diff platforms. I'll leave a very summarized one here.
I think the guy's heart is in the right place, but he's missing the spirit entirely. The whole thing breathes an air of unwarranted self-important presumed authority. That said, I think there are valid criticisms in terms of security certification or file transfer (although I resent they assume it's ALL text/plain, being the mod of s/music smfh) but some of which @skyjake 's apps have given very accessible solutions to.
That's about it for my say in this, i'm sure i'll have more to post about later lolol.