💾 Archived View for gemi.dev › gemini-mailing-list › 000852.gmi captured on 2023-11-04 at 13:09:19. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
The updated protocol (only) specification is now up and can be read at: https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi I haven't closed the issues related to this, but I did comment on each issue: https://gitlab.com/gemini-specification/protocol/-/issues The specification has been run by Solderpunk and he had no major issues with what has been written. As a reminder---this is *just the protocol* itself. I have yet to finish up on the text format. -spc
Sean Conner writes:
> The updated protocol (only) specification is now up and can be read
> at:
Thanks for all of your work on this. I haven't read it over yet, but I'm
sure I'll have comments when I'm able to.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
Thank you for your work on this! It's great to see this protocol mature! ~almaember
On Mon, 2021-04-05, Sean Conner wrote: > > The updated protocol (only) specification is now up and can be read at: > > https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi Thank you. A few thoughts: I recommend making each change in a separate commit, to make it easier to isolate and comment on. In a huge diff like this [1] it's easy to miss small, but important changes. [1] https://gitlab.com/gemini-specification/protocol/-/commit/0235100151b57 d9f5c3384acdacb4ad9986f7ae4?expanded=1&view=inline > The use of an existing TLS library SHOULD be used, but because not all > existing TLS libraries support TLS 1.3, then at this time (2021), > implementations MUST support TLS version 1.2 or higher. You probably meant to start with "An existing TLS library SHOULD be used", but what does this actually mean? Existing as of when? If someone makes a new TLS library, it will also exist. Also, many libraries are abandoned, so it will never be the case that "all existing TLS libraries" will support TLS 1.3, or even 1.2. I don't think the final Gemini specification should mention libraries at all. They may be ok as a temporary justification for why TLS 1.2 is in the spec, but let's see if we can get more clarity on this: what exactly are we waiting for before TLS 1.3 becomes the minimum version? Support in BearSSL (which may never be added)? Support in X% of clients and Y% of servers? Hard to say, isn't it? > TLS 1.2 will send the server name and the client certificate (if used) > in the clear TLS 1.3 also sends the server name (SNI) in the clear, unless ECH/ESNI is used. The issue here is that TLS 1.2 is not compatible with ECH/ESNI. But even with TLS 1.3, public keys need to be put in DNS in order for ECH/ESNI to work, so it will probably not be a mainstream feature (although it should be encouraged). > A client MAY warn a user of a TLS 1.2 connection is established, and > SHOULD warn the user of a client certifiate will be transmitted via > TLS 1.2. It's "if" rather than "of", right?
On Mon, Apr 5, 2021 at 8:19 PM Sean Conner <sean at conman.org> wrote: > > The updated protocol (only) specification is now up and can be read at: > > > https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi > > I haven't closed the issues related to this, but I did comment on each > issue: > > https://gitlab.com/gemini-specification/protocol/-/issues > > The specification has been run by Solderpunk and he had no major issues > with what has been written. > > As a reminder---this is *just the protocol* itself. I have yet to finish > up on the text format. > > -spc > Thanks Sean. I love the progress... I have quite a lot of feedback and adjustments. I'm filing tickets as I see the adjustment while reading through the spec - hopefully that's an acceptable way for me to help.
It was thus said that the Great nervuri once stated: > On Mon, 2021-04-05, Sean Conner wrote: > > > > The updated protocol (only) specification is now up and can be read at: > > > > https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi > > Thank you. A few thoughts: > > I recommend making each change in a separate commit, to make it easier > to isolate and comment on. In a huge diff like this [1] it's easy to > miss small, but important changes. Further changes should be less massive. I know this change is large, but only because I felt it easier to just rewrite the document from scratch than try to adjust the existing one. > [1] > https://gitlab.com/gemini-specification/protocol/-/commit/0235100151b57d9 f5c3384acdacb4ad9986f7ae4?expanded=1&view=inline > > >The use of an existing TLS library SHOULD be used, but because not all > >existing TLS libraries support TLS 1.3, then at this time (2021), > >implementations MUST support TLS version 1.2 or higher. > > You probably meant to start with "An existing TLS library SHOULD be > used", but what does this actually mean? Existing as of when? If > someone makes a new TLS library, it will also exist. Also, many > libraries are abandoned, so it will never be the case that "all existing > TLS libraries" will support TLS 1.3, or even 1.2. Okay, I reworked this paragraph: At the time of writing (2021), not all existing TLS libraries support TLS 1.3, but a majority (all?) do support TLS 1.2, thus TLS 1.2 is the minimum required version. Implementations MUST support TLS SNI (Server Name Indication), and servers MUST use the TLS close_notify implementation to close the connection. Clients SHOULD NOT close a connection by default, but MAY in case the content exceeds constraints set by the user. > I don't think the final Gemini specification should mention libraries at > all. They may be ok as a temporary justification for why TLS 1.2 is in > the spec, but let's see if we can get more clarity on this: what exactly > are we waiting for before TLS 1.3 becomes the minimum version? Support > in BearSSL (which may never be added)? Support in X% of clients and Y% > of servers? Hard to say, isn't it? One reason was the use of LibreSSL, which (until relatively recently) only support TLS 1.2, and there were several large sites using LibreSSL (including mine, until I switched to using OpenSSL and libretls). Also, stats [1] show that some 21% of Gemini sites still use TLS 1.2. Personally, I think that once this falls below 5% (or greater than 95% of all sites support TLS 1.3) we can revisit this decision. > >TLS 1.2 will send the server name and the client certificate (if used) > >in the clear > > TLS 1.3 also sends the server name (SNI) in the clear, unless ECH/ESNI > is used. The issue here is that TLS 1.2 is not compatible with > ECH/ESNI. But even with TLS 1.3, public keys need to be put in DNS in > order for ECH/ESNI to work, so it will probably not be a mainstream > feature (although it should be encouraged). This, I did not know. I'm not sure what to say about this. > >A client MAY warn a user of a TLS 1.2 connection is established, and > >SHOULD warn the user of a client certifiate will be transmitted via > >TLS 1.2. > > It's "if" rather than "of", right? Yes, fixed. Thanks. -spc [1] gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi
It was thus said that the Great Mansfield once stated: > > Thanks Sean. I love the progress... I have quite a lot of feedback and > adjustments. > > I'm filing tickets as I see the adjustment while reading through the spec - > hopefully that's an acceptable way for me to help. Yes, that's great! I kept the existing tickets open for this reason. -spc
On Wed, 2021-04-07, Sean Conner wrote: >Also, stats [1] show that some 21% of Gemini sites still use TLS 1.2. >Personally, I think that once this falls below 5% (or greater than 95% >of all sites support TLS 1.3) we can revisit this decision. Ok. We should also test clients. I was working on that, but other things took priority. Also, if the actual blocker is the percentage of servers and clients supporting TLS 1.3, then that's what the specification should say, rather than referring to libraries. It can be vague, like: > TLS 1.2 is reluctantly permitted until TLS 1.3 support is more > widespread among Gemini servers and clients. The minimum required TLS > version is 1.2, but clients who wish to be "ahead of the curve" MAY > refuse to connect to servers using TLS version 1.2. > > Implementations MUST support TLS SNI... This would be closer to Solderpunk's original text.
On Thu, 08 Apr 2021 16:59:31 +0000, nervuri wrote:
> On Wed, 2021-04-07, Sean Conner wrote:
>> Also, stats [1] show that some 21% of Gemini sites still use TLS 1.2.
>> Personally, I think that once this falls below 5% (or greater than 95%
>> of all sites support TLS 1.3) we can revisit this decision.
>
> Also, if the actual blocker is the percentage of servers and clients
> supporting TLS 1.3, then that's what the specification should say,
> rather than referring to libraries. It can be vague, like:
>
> TLS 1.2 is reluctantly permitted until TLS 1.3 support is more
> widespread among Gemini servers and clients.
> The minimum required TLS version is 1.2,
> but clients who wish to be "ahead of the curve" MAY
> refuse to connect to servers using TLS version 1.2.
Could we even formulate without specifying version numbers, not knowing
which version Gemini should be using in like a decade? Somewhat along:
Servers and clients must use TLS. The current (stable) TLS version should
be supported; the next lower version may be supported as long as
a) this lower version is not [commonly] considered insecure [by whom?]
and
b) the majority of [common] TLS libraries do not [yet] support the
current TLS version in the libraries' stable versions.
Not too sure about a) and the "common" parts, though.
Thx
Perhaps it could mention something about published vulnerabilities or crackability with consumer hardware, as a response to the [by whom?] that nervuri mentions here. I think library support is also important to make sure that any implementations are done well and that people aren't trying to rush a standard without proper support, leading to more bugs and opportunities for malicious attacks. - Entflammen On Thu, Apr 8, 2021 at 4:00 PM <text at sdfeu.org> wrote: > On Thu, 08 Apr 2021 16:59:31 +0000, nervuri wrote: > > > On Wed, 2021-04-07, Sean Conner wrote: > >> Also, stats [1] show that some 21% of Gemini sites still use TLS 1.2. > >> Personally, I think that once this falls below 5% (or greater than 95% > >> of all sites support TLS 1.3) we can revisit this decision. > > > > Also, if the actual blocker is the percentage of servers and clients > > supporting TLS 1.3, then that's what the specification should say, > > rather than referring to libraries. It can be vague, like: > > > > TLS 1.2 is reluctantly permitted until TLS 1.3 support is more > > widespread among Gemini servers and clients. > > The minimum required TLS version is 1.2, > > but clients who wish to be "ahead of the curve" MAY > > refuse to connect to servers using TLS version 1.2. > > Could we even formulate without specifying version numbers, not knowing > which version Gemini should be using in like a decade? Somewhat along: > > Servers and clients must use TLS. The current (stable) TLS version should > be supported; the next lower version may be supported as long as > a) this lower version is not [commonly] considered insecure [by whom?] > and > b) the majority of [common] TLS libraries do not [yet] support the > current TLS version in the libraries' stable versions. > > Not too sure about a) and the "common" parts, though. > > Thx > >
---