Re: Session-Id

> This is incorrect.  Allowing the client to decide on the key value
> will not make the privacy problems go away.

No; nothing will make them go away. Especially not if the client
*cooperates* as you suggest:

> First, if the client uses same the session-ID key for every server

> Now, if the user agent uses a different session-id for each server it
> talks to, the above tracking is made much more difficult, if not
> completely infeasible.  Assuming that the user agent does not send
> Referer: info, of course.

That was the point of allowing the client to override a
server-generated session id.

> I see no need for your proposed symmetrical session-id mechanism, in
> which (if I understand it correctly) clients have the option to
> renegotiate on the session key proposed by a server.  The option for
> such renegotiation does not solve any privacy problems that are not
> solved by putting `one server only' restrictions on an asymmetrical
> mechanism.

Yes, but going to a symmetric mechanism ends the debate about whether
id's should be generated by the server or the client. Allowing both
allows an application to use whichever is better for that application.
Allowing the client to insist on it being allowed to genearate the
session id solves any privacy problems associated with
server-generated session ids.

Yes, this allows clients to create a single session ID and use it when
talking to all servers. That's a bad idea. Does that mean we have to
require that a client not do that? I think such a requirement would be
a bad idea. Any documentation on such a standard should include a
SECURITY section that covers these issues.

	<mike

Received on Monday, 24 July 1995 23:05:20 UTC