Status codes

[Sean Conner]

It was thus said that the Great Dominik Dalek once stated:
> Howdy!

  Hello.

  [bit ol' snip]

> Suggestion #1: Remove proxy related codes

  [ snip ]

> How server and client certs are handled in the proxy scenario is also
> something that I don't think is trivial and as such would require some
> legwork to get up and running. So, yeah, I'd cut any mention of proxy
> at the moment and with that's codes 43 and 53.

  There are at least two Gemini servers that handle proxying to various
degrees (to my knowledge).  I expect changes, but not removal.

> Suggestion #2: Deduplicate client cert errors
> 
> Only a single client cert can be sent when establishing the communication
> channel. My mental model (correct me if I'm wrong!) is that transient
> cert is a session substitute and permanent cert is authentication
> mechanism (roughly speaking at least).
> 
> Current spec has 3 cert request mechanisms, 3 rejection codes and
> a revocation code. This creates numerous corner cases for clients
> to handle properly, e.g.
> * what do you do if you get 21 in response to a request that included
> your permanent key? I sure hope the browser doesn't actually delete
> the permanent key from the store :)
> * what do you do if you get 64 but your cert is not from the future?
> * what do you do if you get 65 but your cert hasn't expired?

  Both of those indicate either

	1) a buggy server
	2) a buggy client
	2) the client clock is incorrect
	3) the server clock is incorrect

  I would only really expect to see these around the time of certificate
expiry (or certificate creation).

> I'd like to see a single "client certificate rejected" code eliminating
> responses that would potentially make no sense.
> 
> I feel that differentiating between the types of rejection opens some
> opportunity for oracle attacks (i.e. rogue clients can inspect server
> cert processing bugs by observing how responses differ for various
> crafted requests). In essence I'd cut 64 and 65.

  I don't agree.  I don't have a fully fleshed out response to the "but muh
security!" argument (well, there is "security through obscurity" isn't) but
it's rooted around the following story:

	Ken Thompson [creator of C and Unix] has an automobile which he
	helped design.  Unlike most automobiles, it has neither speedometer,
	nor gas gage, nor any of the numerous idiot lights which plague the
	modern driver.  Rather, if the driver makes any mistake, a giant "?"
	lights up in the center of the dashboard.  "The experienced driver",
	he says, "will usually know what's wrong."

  I've done tech support and have had to deal with "it's broke---fix it!"
questions with nothing more than that.  I'd rather not do that again.

> Suggestion #3: Change end of cert session (21) into a redirection
> 
> This will probably be a very controversial one but the way I see it
> the end of session typically results in the redirection. This lets you
> chain requests on logout in a way that enables permanent client key
> delivery or temporary key replacement. With current design you serve
> a page in a response to a request that displays something and asks
> the client to delete the transient cert. If you want to re-establish
> some sort of validation from the client, you need a manual intervention
> from the user to do that. I'm not sure if my explanation is clear enough,
> I can try and expand upon it if needed.

  It might help to test against a server that actually implements this.  I
kind of see what you are getting at, and a "logout" mechanism is solely
missing from HTTP (if you are using the actual authentication mechanism and
not HTTP cookies), but I'm not exactly sure what your objection here is.

> Suggestion #4: Merge different types of server error to prevent leaking
> what happened under the hood

  See above---we'll have to agree to disagree on this.

> HTTP 500 is often seen as an indication of something wrong in the server
> application logic. This would be the primary attack vector for someone
> trying to compromise the server (even if only DOS it). I don't think it
> makes sense to differentiate codes 40-42 with the exception maybe of
> a planned maintenance. Basically I'm sort of allergic to disclosing
> information about the server state.

  Nothing to stop a server from just serving up '40' for everything.

> Suggestion #5: A comment, really

  The 40 range of codes map to HTTP 500 range (server errors), and the 50
range of codes map to HTTP 400 range (client errors), and when I first wrote
GLV-1.12556, I used HTTP status codes (because I felt the original status
codes were ... less than optimal), but later solderpunk renamed "client
errors" to "permanent errors" and "server errors" to "temporary errors" (I
think he gave some justification for this, but I don't recall what it was).

> 5x codes are by design permanent errors but 51 (HTTP 404 equivalent) is
> actually a temporary problem according to the spec.
> In fact this is precisely what differentiates it from HTTP 410 GONE
> (gemini 52). So there seems to be a design error here but I don't really
> know what the correct solution is. Either 5x aren't really permanent
> errors (how would they be called then?) or 51 shouldn't be a 5x error
> to begin with.

  It starts to make sense when you realize they were originally server and
client errors.

  But let me be fair, and report back all the errors that GLV-1.12556 can
return (modulo what a CGI scripts and the torture test):

	10	prompt for input
	20	okay
	30	temporary redirect
	31	permament redirect
	40	temporary error
	51	not found
	52	gone
	59	bad request
	61	transient certificate
	62	authorized certificate
	63	certificate rejected
	64	future certificate
	65	expired certificate

  Even my CGI module only returns 40 (if it can't run a CGI script for
whatever reason).  

> This sums up my thoughts about the status codes. I know this reads very
> much like "too complex, cut!" and that kinda is exactly that. But if you
> can make things simpler, why not do it? :)

  It broke.  Fix it. 8-P

  -spc