💾 Archived View for gemi.dev › gemini-mailing-list › 000570.gmi captured on 2024-05-26 at 16:12:24. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Greetings all, I'm trying to prepare a list of spec issues that I want to finalise as soon as possible. I probably should have been more disciplined about this, but the high traffic rate of the mailing list combined with the fact that an awful lot of the discussion is about stuff that I'm not interested in means I've kind of lost track of the important things. Below is everything I'm aware of which has been previously raised which I think is worthy of some kind of consideration/response. If you think I've forgotten something, please let me know. In arbitrary order:
On Sun, 27 Dec 2020, Solderpunk wrote: > I think is worthy of some kind of consideration/response. If you think > I've forgotten something, please let me know. You posted on your gemlog some time ago that the experience of the use of TLS client certificates had raised issues that needed to be clarified in the spec; I don't know whether these issues were satisfactorily resolved. => gemini://gemini.circumlunar.space/users/solderpunk/gemlog/tls-musings.gmi For my own part I'd like to know about timeouts. My server is coded with some concern about DoS attacks such as the Slow Loris attack: => https://en.wikipedia.org/wiki/Slowloris_(computer_security) To mitigate this, the server shuts down any connection which hasn't submitted a request after ten seconds. Pragmatically, client authors do not need licence from the spec to implement a timeout, but it may be useful to constrain when and how server implementors should/must/must not do this. Mk -- Martin Keegan, @mk270, https://mk.ucant.org/
On Sun Dec 27, 2020 at 1:01 PM CET, Martin Keegan wrote: > You posted on your gemlog some time ago that the experience of the use > of > TLS client certificates had raised issues that needed to be clarified in > the spec; I don't know whether these issues were satisfactorily > resolved. > > => > gemini://gemini.circumlunar.space/users/solderpunk/gemlog/tls-musings.gmi Thanks for the reminder! The SNI issue was addressed and this is now mentioned in the spec. The status codes related to client certificates were also simplified and "transient certificates" are no longer a first-class concept in the spec. I *think* those were the major issues that a little real-world experience revealed, and that they are both now resolved. > For my own part I'd like to know about timeouts. My server is coded with > some concern about DoS attacks such as the Slow Loris attack: > > => https://en.wikipedia.org/wiki/Slowloris_(computer_security) > > To mitigate this, the server shuts down any connection which hasn't > submitted a request after ten seconds. Pragmatically, client authors do > not need licence from the spec to implement a timeout, but it may be > useful to constrain when and how server implementors should/must/must > not > do this. Hmm. While I agree that neither servers nor clients really need permission to implement basic functionality like timeouts, this particular case *does* raise some questions. Currently it seems implicit in the spec that servers may not say anything until the client has finished sending a request. In principle, there are circumstances where a server might know what it wants to do before that point - an invalid URL (triggering a status code 59 response) might be detected before it is complete, and the n-th request within m seconds (triggering a status code 44 response) can be detected before *anything* is received. And, as you point out, reasonable defensive timeouts can occur before a request is complete. Is a server obligated to wait for a complete response before saying anything? Thanks for bringing this up, I'll think about it. Thoughts are welcome. Cheers, Solderpunk
> On Dec 27, 2020, at 13:25, Solderpunk <solderpunk at posteo.net> wrote: > > Is a server obligated to wait for a complete response before saying anything? No. It's unreasonable to mandate any QoS (Quality of service) anywhere. Both clients and servers are free to take any defensive measures they see fit. Or none. It's their call.
> 27 dec. 2020 kl. 15:18 skrev Petite Abeille <petite.abeille at gmail.com>: > > ? > >> On Dec 27, 2020, at 13:25, Solderpunk <solderpunk at posteo.net> wrote: >> >> Is a server obligated to wait for a complete response before saying anything? > > No. It's unreasonable to mandate any QoS (Quality of service) anywhere. Both clients and servers are free to take any defensive measures they see fit. Or none. It's their call. > I completely agree with this. It?s in the server?s interest to strike a balance between defensive measures and good service as best they can given their situation. Cheers, ew0k
On Sun Dec 27, 2020 at 3:35 PM CET, Bj?rn W?rmedal wrote: > > > 27 dec. 2020 kl. 15:18 skrev Petite Abeille <petite.abeille at gmail.com>: > > > > No. It's unreasonable to mandate any QoS (Quality of service) anywhere. Both clients and servers are free to take any defensive measures they see fit. Or none. It's their call. > > > I completely agree with this. It?s in the server?s interest to > strike a balance between defensive measures and good service as best > they can given their situation. Thanks, both of you. This is consistent with some changes I've already started drafting. I'll send another email around with some proposed changes relatively soon. Cheers, Solderpunk
> I'm trying to prepare a list of spec issues that I want to finalise as > soon as possible. Thanks! This is helpful. Fingers crossed it doesn't become a monster megathread... Also, I believe you've missed my small spec changes I proposed a while ago, which have to do with the lang param. See these emails. gemini://gemi.dev/gemini-mailing-list/messages/003827.gmi gemini://gemi.dev/gemini-mailing-list/messages/003911.gmi Cheers, makeworld
On Sun Dec 27, 2020 at 5:38 PM CET, wrote: > Also, I believe you've missed my small spec changes I proposed a while > ago, > which have to do with the lang param. See these emails. > > gemini://gemi.dev/gemini-mailing-list/messages/003827.gmi > gemini://gemi.dev/gemini-mailing-list/messages/003911.gmi Ah, thanks. These should, indeed, be dealt with. But it's thankfully very clear what to do and there's no discussion needed. This will get fixed in the next update (sometime before the end of this year!). Cheers, Solderpunk
On 2020-12-27T10:47Z, Solderpunk wrote among other things: > * Clarification on the use of TLS close_notify has been requested. >?? This is actually mandated by both TLS 1.2 and 1.3 specs so technically >?? it's redundant to mention it in the Gemini spec, but given how poorly >?? implemented it is, some explicit reminding could not hurt.? I think >?? there's a tiny wrinkle to consider here on *when* the client should >?? send this (due to a change in semantics between TLS 1.2 and 1.3). > * The spec is a bit vague on under which circumstances the META part of >?? a response header may be empty, and on exactly what that means (e.g. >?? is a tab after the status code still required in any case?). This >?? needs to be tightened up, and I'm pretty sure this should be done by >?? just making non-empty META a requirement. As you have now mentioned these two issues, there was a mail with these two and another issue[1], namely if lone LFs (or lone CRs or other line breaking code points for that matter) are allowed inside META. Johann [1] gemini://gemi.dev/gemini-mailing-list/messages/003276.gmi --- You can verify the digital signature on this email with the public key available through web key discovery. Try e.g. `gpg --locate-keys`... -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/0895 ac48/attachment-0001.sig>
On Sun, Dec 27, 2020 at 6:23 AM Solderpunk <solderpunk at posteo.net> wrote: > * The spec is a bit vague on under which circumstances the META part of > a response header may be empty, and on exactly what that means (e.g. > is a tab after the status code still required in any case?). This > needs to be tightened up, and I'm pretty sure this should be done by > just making non-empty META a requirement. > If empty META strings are going to be invalid (I think they should be), then the last graf of 3.3 should be deleted.
On Sun Dec 27, 2020 at 8:35 PM CET, John Cowan wrote: > On Sun, Dec 27, 2020 at 6:23 AM Solderpunk <solderpunk at posteo.net> > wrote: > If empty META strings are going to be invalid (I think they should be), > then the last graf of 3.3 should be deleted. Agreed, this was one of the changes in my recent "Proposed changes" post. Cheers, Solerpunk
On Sun Dec 27, 2020 at 6:54 PM CET, Johann Galle wrote: > As you have now mentioned these two issues, there was a mail with these > two and > another issue[1], namely if lone LFs (or lone CRs or other line breaking > code > points for that matter) are allowed inside META. > > [1] gemini://gemi.dev/gemini-mailing-list/messages/003276.gmi Hmm. Currently this is perfectly legal. I agree that it's not unlikely there will be hastily written clients which don't handle it correctly (although it could easily be included in Sean's torture test suite), but I'm not sure that's a reason in and of itself to forbid it. Can anybody think of any any strong arguments in either direction? Cheers, Solderpunk
It was thus said that the Great Solderpunk once stated: > On Sun Dec 27, 2020 at 6:54 PM CET, Johann Galle wrote: > > > As you have now mentioned these two issues, there was a mail with these > > two and another issue[1], namely if lone LFs (or lone CRs or other line > > breaking code points for that matter) are allowed inside META. > > > > [1] gemini://gemi.dev/gemini-mailing-list/messages/003276.gmi > > Hmm. Currently this is perfectly legal. I agree that it's not unlikely > there will be hastily written clients which don't handle it correctly > (although it could easily be included in Sean's torture test suite), but > I'm not sure that's a reason in and of itself to forbid it. Can anybody > think of any any strong arguments in either direction? Okay, this is about: 10 Is\nThis\nValid?\r\n While this is valid per the spec, I would recommend against embedded control codes in the META response. Arbitrary control codes can do some pretty nasty things [1], and this can potentially mess up a client's display. Clients (in my opinion) should strip out such sequences, if only because this is trying to influence how the client display text. -spc [1] Redefine the keyboard, issue commands to the operating system, application or device for instance. I don't know of any current terminal software that support the commands, but I do know of at least one operating system where you can redefined the keyboard via control codes, and it's a very popular operating system. Like, *the* most popular operating system.
> On Dec 28, 2020, at 00:21, Sean Conner <sean at conman.org> wrote: > > Clients (in my opinion) should strip out such sequences, if only > because this is trying to influence how the client display text. Agree. Actually, client MUST sanitize all input, irrespectively of origin. Not doing so would be highly irresponsible. This would be easier if META would not legally contain any control characters to start with.
Hello, I have a suggestion to add to the list and a question on parsing quote lines. > I'm trying to prepare a list of spec issues that I want to finalise as > soon as possible. If you think I've forgotten something, please let me know. The current spec suggests supporting TOFU. I think you may want to consider also supporting using the default/system certificate authority trust system as a fallback. This allows certificates signed by Let's Encrypt or others to be used without the client having to store the known certificate. It also allows server operators to renew certificates without breaking clients. This might be the behavior of clients today (trust system trusted CAs or use TOFU), but it's nice to have clearly defined behavior. > * There's this long-standing issue of the fact that none of the > character sequences which identify the start of a non-text line type > were originally defined with spaces after them, but we've added that > requirement hodge-podge as ambiguities have appeared, and now we're in > a situation where half the line types need them and half don't. > Consistency suggests we require spaces everywhere, but this has been > surprisingly controversial and may break some things. But a final > ruling is required. I've been wondering about this... Specifically, in these example scenarios: Sans whitespace: >This is a quote With whitespace: > This is a quote Should these two be parsed the same or should one include leading whitespace? ----- Also, are you open to suggestions/additions to the text/gemini format? -- Kind regards, Kiba
On Mon, Dec 28, 2020 at 12:27:15AM +0100, Petite Abeille wrote: > This would be easier if META would not legally contain any control > characters to start with. Won't be easier - malicious servers would just do it anyways. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/40b1 2613/attachment.sig>
On 2020-12-28T11:27Z, Petite Abeille wrote: > This would be easier if META would not legally contain any control > characters to start with. On 2020-12-28T21:27Z, Arav K. replied: > Won't be easier - malicious servers would just do it anyways. If it is forbidden, we could just filter out control code points without worring about destroying valid use cases. Although I wonder what those would be. Johann --- You can verify the digital signature on this email with the public key available through web key discovery. Try e.g. `gpg --locate-keys`... -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201229/fcce 822a/attachment-0001.sig>
> On Dec 29, 2020, at 02:01, Johann Galle <johann at qwertqwefsday.eu> wrote: > > If it is forbidden, we could just filter out control code points without worring > about destroying valid use cases. Genau. > Although I wonder what those would be. Smuggling ASCII art in response status? :D
Solderpunk <solderpunk at posteo.net> writes:
> Greetings all,
>
> I'm trying to prepare a list of spec issues that I want to finalise as
> soon as possible. I probably should have been more disciplined about
> this, but the high traffic rate of the mailing list combined with the
> fact that an awful lot of the discussion is about stuff that I'm not
> interested in means I've kind of lost track of the important things.
> Below is everything I'm aware of which has been previously raised which
> I think is worthy of some kind of consideration/response. If you think
> I've forgotten something, please let me know.
A few other issues that have come up and could use spec-level
clarification:
1. What are the valid/invalid/recommended values for CN, SAN, and
expiration dates in certificates in the context of TOFU?
It has been suggested on the mailing list that none of these values
should have meaning under a TOFU security model. Others argue that
they should have specific values and meanings. Clarity would be
appreciated.
2. Client use of URL fragments (jump to heading, full text search, etc.)
Arguments for a variety of options (including none) have already been
presented in another mailing list thread.
3. Extending bulleted lists to three level to match headings (*, **, ***)
Gemtext only defines a single-level unordered list line type (*). It
was shown on the mailing list some time ago that different clients
may have quite different ways of rendering attempts by authors to
create nested list outlines. Here are two examples, both of which
have variable renderings depending on the client used:
* TODOs
** Work
*** Check email
*** Be productive
** Home
*** Eat food
*** Clean body
*** Get off your couch occasionally
* TODOs
* Work
* Check email
* Be productive
* Home
* Eat food
* Clean body
* Get off your couch occasionally
It seems (at least to my eyes), that the (*, **, ***) examples are
more in line with Gemini's 3-character line type indicator rule and
match the same style as the three heading levels (#, ##, ###). Adding
these to the Gemtext spec should be a strictly accretive (and
therefore non-breaking) change that would standardize their display
in different Gemini browsers.
4. Providing a concrete example of how to use text after opening ``` to
specify client behavior (e.g., source code highlighting).
The Gemini spec mentions that the alt text can be used for this
purpose but doesn't provide any clear mechanism for how this should
be done. This leaves the choice entirely up to different clients,
which seems like a recipe for competing browser wars and "Best Viewed
In" notes on Gemtext pages. This is probably less than ideal.
Okay, that's all I can think of at the moment. Good luck mulling all
these issues over.
Happy hacking,
Gary
--
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Why is HTML email a security nightmare? See https://useplaintext.email/
Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
> On Jan 5, 2021, at 21:17, Gary Johnson <lambdatronic at disroot.org> wrote: > > 1. What are the valid/invalid/recommended values for CN, SAN, and > expiration dates in certificates in the context of TOFU? TOFU, as practiced by ssh & co., is about key exchange. One accepts a key, from a given host. There is no notion of "certificates", much less X.509 certificates, just a host+key pair. Certificates should be entirely ignored as far as TOFU goes. And only viewed as a way to transfer the key. An envelope for the key, due to TLS. Trying to merge the semantic of the X.509 certificates PKI and TOFU is not TOFU anymore. SEITAN perhaps. An entirely different construct for sure. ? ???
On Tue, Jan 05, 2021 at 03:17:00PM -0500, Gary Johnson <lambdatronic at disroot.org> wrote a message of 89 lines which said: > 1. What are the valid/invalid/recommended values for CN, SAN, and > expiration dates in certificates in the context of TOFU? Also, regarding TOFU (probably the worst part of the current specification), there are many other clarifications requested:
On Tue, Jan 05, 2021 at 03:17:00PM -0500, Gary Johnson <lambdatronic at disroot.org> wrote a message of 89 lines which said: > A few other issues that have come up and could use spec-level > clarification: A personal list of what I think are the issues with Gemini specification: gemini://gemini.bortzmeyer.org/gemini/missing.gmi
Two privacy-related suggestions: # Only send client certificates over TLS 1.3 TLS 1.3 encrypts client certs, TLS 1.2 doesn't. On 1.2 your ISP might see the user you log in as, your e-mail address and whatever other information you (are required to) put in the cert. Please consider only allowing client certificates over TLS 1.3 (and newer). # No OCSP requests The spec says: > Clients can validate TLS connections however they like As long as CA-based validation is allowed in Gemini, consider adding an exception along the lines of "Thou shalt not make OCSP requests", as they are notoriously bad for privacy, add latency and are easy to block by attackers.
On Sun, 10 Jan 2021, Stephane Bortzmeyer wrote: > A personal list of what I think are the issues with Gemini > specification: > > gemini://gemini.bortzmeyer.org/gemini/missing.gmi I am loath to raise these kinds of things, as it just creates more work, but if you're taking requests: Clarify whether gemini://host.domain/path and gemini://host.domain:1965/path are to be considered equivalent, and if so, what that means. (This may be more important for the robots.txt side-spec). Mk -- Martin Keegan, @mk270, https://mk.ucant.org/
> On Jan 10, 2021, at 18:42, Martin Keegan <martin at no.ucant.org> wrote: > > Clarify whether gemini://host.domain/path and gemini://host.domain:1965/path are to be considered equivalent, and if so, what that means. (This may be more important for the robots.txt side-spec). This is outside of Gemini's specification remit, but yes, they are equivalent. See URI normalization: https://en.wikipedia.org/wiki/URI_normalization ? ???
> On Jan 6, 2021, at 09:25, Stephane Bortzmeyer <stephane at sources.org> wrote: > > * interactions between TOFU and valid certificates. For instance, > should a client disable TOFU when the certificate is valid? The current assumptions are wholly incoherent. The interaction between TOFU and X.509, if any, must be thought through clearly. This is not even half-baked. It's not baked at all. ? ???
On Sun, Jan 10, 2021 at 05:42:34PM +0000, Martin Keegan <martin at no.ucant.org> wrote a message of 20 lines which said: > Clarify whether gemini://host.domain/path and > gemini://host.domain:1965/path are to be considered equivalent, and > if so, what that means. (This may be more important for the > robots.txt side-spec). Yes, they are equivalent. RFC 3986 <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3986.txt>, section 3.2.3: A scheme may define a default port. For example, the "http" scheme defines a default port of "80", corresponding to its reserved TCP port number. [...] URI producers and normalizers should omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of the scheme's default. For instance, the Lupa crawler <gemini://gemini.bortzmeyer.org/software/lupa/> canonicalizes <gemini://host.example:1965/path> to <gemini://host.example/path>. % lupa-insert-url gemini://host.example:1965/path URL gemini://host.example:1965/path added to the database (ID 152155, capsule ID 571) % my-lupa-insert-url gemini://host.example/path URL gemini://host.example/path already in the database
>The interaction between TOFU and X.509, if any, must be thought through clearly. I'm not writing a client right now, but if I was, I think I would handle certs a few different ways. First, if it was tunneled over a protocol that is already encrypted (ex. Tor), I'd accept any certificate, because TLS would be redundant, even though the spec requires it. If the certificate was valid and trusted by the CAs installed, I would also accept it, even if that means overwriting an earlier TOFU entry. Otherwise, I would handle them like SSH handles keys, by asking the user on the first connection if the certificate is trusted. Hopefully blockchain-based naming systems will make cert validation easy some day, as you could just check if the cert matches the signature in the blockchain of the person who owns the domain.
> On Jan 11, 2021, at 20:47, easrng <easrng at gmail.com> wrote: > > I'm not writing a client right now, but if I was, I think I would > handle certs a few different ways. First, if it was tunneled over a > protocol that is already encrypted (ex. Tor), I'd accept any > certificate, because TLS would be redundant, even though the spec > requires it. Good point. I actually do that over wireguard -using old school ident at time- LAN type ala tailscale ?. No point for TLS in such setup. It was suggested to move TLS outside of the core protocol (i.e. gemini+plain), and precisely define TLS as a Gemini "profile", i.e. gemini+tls. No traction :P > If the certificate was valid and trusted by the CAs > installed, I would also accept it, even if that means overwriting an > earlier TOFU entry. Otherwise, I would handle them like SSH handles > keys, by asking the user on the first connection if the certificate is > trusted. Hopefully blockchain-based naming systems will make cert > validation easy some day, as you could just check if the cert matches > the signature in the blockchain of the person who owns the domain. This is all sounds rather reasonable. The part I don't really like personally is the mixed metaphor of ( TOFU + X.509 ) = ? ? ??? ? https://tailscale.com/blog/remembering-the-lan/
> On Jan 11, 2021, at 21:10, Petite Abeille <petite.abeille at gmail.com> wrote: > > It was suggested to move TLS outside of the core protocol (i.e. gemini+plain), and precisely define TLS as a Gemini "profile", i.e. gemini+tls. Using multiaddr notation ?: /dns4/service.local/tcp/1965/tls/gemini/endpoint/ -- gemini+tls vs. /dns4/service.local/tcp/1966/gemini/endpoint/ -- gemini+plain ? https://multiformats.io/multiaddr/ ? ???
On Mon, Jan 11, 2021 at 02:47:40PM -0500, easrng <easrng at gmail.com> wrote a message of 12 lines which said: > I think I would handle certs a few different ways. [...] If the > certificate was valid and trusted by the CAs installed, I would also > accept it, even if that means overwriting an earlier TOFU > entry. Otherwise, I would handle them like SSH handles keys, by > asking the user on the first connection if the certificate is > trusted. It seems a reasonable choice. (Except that "asking the user [...] if the certificate is trusted" is just playing with words: unlike SSH, the user has zero knowledge of the remote server and cannot assess the certificate.) I like the way it deals with the coexistence X.509/TOFU. > First, if it was tunneled over a protocol that is already encrypted > (ex. Tor), I'd accept any certificate, because TLS would be > redundant, Depending on how the client and the server are ran, they may not know if they use Tor or not. Think socks and stuff like that.
---
Previous Thread: [ANN] announcing the outpost, a kinda sorta reddit-esque forum
Next Thread: [Users] new release of mastodon allow gemini URL