💾 Archived View for gem.benscraft.info › mailing-list › messages › 159 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

-=-=-=-=-=-=-

Re: [spec] The updated speculative specification is now up

- nervuri <nervuri at disroot.org>

@ Tue, 06 Apr 2021 16:50 +0000

Full Thread

Reply to Sean Conner <sean at conman.org>

────────────────────────────────────────────────────────────────────────────────

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/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.

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?

════════════════════════════════════════════════════════════════════════════════

Replies

Reply from Sean Conner <sean at conman.org>