[spec] Regarding the proposal to remove status code 11

PJ vM pjvm742 at disroot.org

Sat Mar 13 20:03:30 GMT 2021

- - - - - - - - - - - - - - - - - - -

Over at Gitlab, people are discussing [1] a potential deprecation ofstatus 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 Icould quickly think of:

a Gemini interface to a service for which the user already has logincredentials (and other cases where one needs to confirm the user is thesame as an identity previously established by other means than acertificate)* any use case for which client certs are simply not portable enough* the equivalent of "changing one's password" seems (not certain aboutthis) quite tedious to do in a world with only client certs, for usecases where the users are pseudonymous

It seems clear to me that login credentials and certs are sufficientlydifferent in practical aspects that certs cannot replace passwordauthentication for all use cases.

So, and this is really my key point: whether one likes it or not, Ithink password authentication will keep being used as long as there is away to give input to the server.

Secondly, let's look at why exactly it is considered a bad idea to putsensitive 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 (bywhich I mean proxies where the TLS connection is with the proxy ratherthan with the destination). Note that all the other problems can beaddressed by client software IF it's possible to distinguish betweensensitive and non-sensitive input. When the server sends 11, the clientcan hide the input the user is typing, and throw away the query aftersending the request, before displaying the URL in the URL bar or savingit in the browsing history.

So actually, if we reason from the assumption that passwordauthentication will happen anyway (as I've argued above), removingstatus code 11 has rather negative consequences, as it removes theability to distinguish between sensitive and non-sensitive input.

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

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

Please excuse the length of this email.

[1] https://gitlab.com/gemini-specification/protocol/-/issues/17

-- pjvm