[spec] Regarding the proposal to remove status code 11

Luke Emmet luke at marmaladefoo.com
Sun Mar 14 09:32:16 GMT 2021

On 13-Mar-2021 20:03, 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
> 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.
Gemini is really a read-only medium as its method is GET only - there is 
no idempotent method to send data. Servers that attempt to put transient 
state with side effects (changing a password among other things) by 
putting these into the URI is poor design IMO.

URIs are designed to be shared, bookmarked - they are a publicly 
persistable reference of server state (see Fielding et al). They are a 
massive success on the internet as such.

A URI query should be thought of as a query parameterisation - a way to 
address server state, rather than as a way to send state to the server. 
To send state properly you need an idempotent mechanism, which Gemini 
doesnt have. The web does, as incidentally did early gopher before it 
adopted URIs. This seems to be a conscious design choice of Gemini.

My view is that status 11 is a kind of security theatre - it gives a 
false sense of security, when in fact it is logically equivalent to 
status 10 - and in fact the spec allows valid clients to only interpret 
the first digit, so a client may actually not know. We should not be 
encouraging its use or authors or users to form a view it is 
"protecting" them in any significant sense.

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

No, its not possible for either clients nor servers to know which URIs 
are "sensitive"

Q: here is a URI - should a client, proxy or server be prevented from 
recording or sharing it:


Ans: there is *no* way to know. It depends on the semantics of the 
application and foo and bar.

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

Status 10 and 11 are currently logically indistinguishable and status 11 
is misleading.

If we keep status 11, the FAQ could warn off its use and I think clients 
should warn users to say something like "The server requested to mask 
the input, however be aware that the parameter will be simply appended 
in the clear to the subsequent URI, and this does not offer a genuine 
security feature."

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

I don't think its a big deal - if the BDFN finds it a useful and 
practical way to gather issues with the spec, I'm happy to contribute 
wherever the conversation may happen.

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

  - Luke

More information about the Gemini mailing list