RE: const time authentication in bozohttpd

> Maybe you choose the delay time to be so long that you are sure that,
> regardless of hardware, load, or any other factors, it will be equal to
> or longer than the greater of path (1) and path (2).  Is the delay time
> actually reasonable at this point, or is it so long that it hurts the
> usability of the authentication?

My suggestion only changes the timing of the *failed* authentication path. I
don't know of any reason why you would want that to be fast, especially if
authenticating for a computer as the client.

If there is some reason why you would want a "fast authentication denial"
for a computer, then (of course) my approach is not useful. I don't know of
any application (computer or human) where the speed of getting an
authentication denial is important. It possibly gets the socket closed more
quickly, which might reduce DoS vulnerability, but there are well known ways
(such as rate limiting connect acceptance) for mitigating that, and I think
one has to do that anyway.  (If I recall correctly, if the opponent hasn't
acked previous messages transmitted to the opponent, the socket has to
linger for a while. And if you're transmitting a denial message, instead of
just closing the socket, I believe you're further at risk for DoS
scenarios.)

If we assume that "slow authentication denial" is acceptable, I would choose
a large number (such 5 seconds). Of course, I'm assuming that the crypto
checks can be done in that interval, but if not then this is moot. If
necessary: during startup, run a dummy authentication and time it. Path 2 is
obviously more work than Path 1, so you just time that. Set your delay to
the larger of 2 ticks of time and 10 * path 2.

Is there a reason that "fast authentication denial" is desirable?

--Terry