[spec] Regarding the proposal to remove status code 11

Thomas Frohwein tfrohwein at fastmail.com
Sun Mar 14 03:30:19 GMT 2021


On Sat, Mar 13, 2021 at 09:03:30PM +0100, PJ vM wrote:
> Over at Gitlab, people are discussing [1] a potential deprecation of
> status code 11 (sensitive input). A few points.
> 
> Firstly, for certain (possibly many) use cases password authentication
> (combined with shorter- or longer-lived "session" client certificates)
> is the right choice over only using client certificates. Some examples I
> could quickly think of:
> 
> * a Gemini interface to a service for which the user already has login
> credentials (and other cases where one needs to confirm the user is the
> same as an identity previously established by other means than a
> certificate)
> * any use case for which client certs are simply not portable enough
> * the equivalent of "changing one's password" seems (not certain about
> this) quite tedious to do in a world with only client certs, for use
> cases where the users are pseudonymous

Agree, especially that it's easier memorize an even complex password than
a client cert if you use different machines.

> It seems clear to me that login credentials and certs are sufficiently
> different in practical aspects that certs cannot replace password
> authentication for all use cases.
> 
> So, and this is really my key point: whether one likes it or not, I
> think password authentication will keep being used as long as there is a
> way to give input to the server.
> 
> Secondly, let's look at why exactly it is considered a bad idea to put
> sensitive information in a URL. The reasons given by RFC 3986 §7.5
> (quoted at the Gitlab issue) are:
> 
> > URIs are frequently displayed by browsers, stored in clear text
> > bookmarks, and logged by user agent history and intermediary
> > applications (proxies)
> The last problem can be avoided by not using relay-type proxies (by
> which I mean proxies where the TLS connection is with the proxy rather
> than with the destination). Note that all the other problems can be
> addressed by client software IF it's possible to distinguish between
> sensitive and non-sensitive input. When the server sends 11, the client
> can hide the input the user is typing, and throw away the query after
> sending the request, before displaying the URL in the URL bar or saving
> it in the browsing history.

Agree. Gemini universe can come up with smart enough clients without a lot
of technical complexity.
 
> So actually, if we reason from the assumption that password
> authentication will happen anyway (as I've argued above), removing
> status code 11 has rather negative consequences, as it removes the
> ability to distinguish between sensitive and non-sensitive input.

Agree.

> My conclusion is that removing status code 11 would be unwise, and
> instead it would be better to include a recommendation in the best
> practices document to throw away the query part after sending a request
> that results from user input on a 11 page. Maybe there should also be a
> recommendation to store client certs in a password-encrypted vault, as
> of course storing long-lived certs unencrypted is about as much of a
> problem as storing sensitive queries in the browsing history.

> Thirdly and lastly, about Gitlab. I strongly dislike the fact that
> discussions which can have quite an impact on all Gemini users are
> happening in Gitlab issues; to stay up-to-date on all these requires
> regularly going through multiple webpages, and to comment requires a
> Gitlab account! I think this is a mistake.

Agree, even with this one.

> Please excuse the length of this email.
> 
> [1] https://gitlab.com/gemini-specification/protocol/-/issues/17
> 
> -- 
> pjvm

I agree pretty much entirely with pjvm's points.


More information about the Gemini mailing list