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:
gemini://example.com/foo?bar
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