[spec] The updated speculative specification is now up

Sean Conner sean at conman.org
Thu Apr 8 03:35:41 BST 2021


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/0235100151b57d9f5c3384acdacb4ad9986f7ae4?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


More information about the Gemini mailing list