Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

On Jun 14, 14:59, Dave Kristol wrote:
> The rejection criteria that I cite apply when the client *receives* a
> cookie.  It's a way to guard against man-in-the-middle attacks.  If you
> allow the origin server (or an adversary) to specify that a cookie can
> be sent to an arbitrary host, you open the possibility of cookie
> leakage.

Dave-

Would this still be the case if the domain issuing the cookie were required to
be included amongst the multiple domains in the cookie?  If the cookie were
constructed so that only friends could its verify its validity over a small
Max-Age, the threat of MITM could be minimized.

> You provide a reasonable example.  However, it's late in the game to
> change the spec to allow for multiple domains.  The current I-D more or
> less ratifies what exists in Netscape (and "compatible" :-) browsers.
> What you ask for would necessarily require client changes and therefore
> probably deserves a new cookie Version number.

Apologies for responding late, but I've been busy but its still before last
call.  I asked you another form of this question in private at the beginning of
the year: Is the purpose of this exercise to describe current practice of one
vendor (who seems to crank out clients at least once per quarter) or to specify
a vendor-neutral somewhat complete generic state mechanism?  Other departures
from the original Netscape Cookie proposal were compromised in the evolution of
this draft, why not this minor tweak that has real-world applications?

A question for those vendors with deployed cookie-capable clients:  Is there a
graceful way for your application to Do The Right Thing in responding to
multiple domain/path cookies it doesn't understand?

While we're here, why are there no client-initiated cookies that could perform
functions (like Phill's or Brian's proposals) or to advertise well-known client
state ('just browsing,' 'purchasing,' 'max $ to spend' or other aspects of
client preference as well as UA-instance ID) to the server.  The client would
need to send the Set-Cookie with each request (or per connection?) to relieve
the server of client-cookie bookkeeping and the server would simply not return
it if it didn't understand client-side cookies or the state assertion.

I'd prefer to see a cleaner design using the same headers with similar yet
complimentary functionality used for both client and server assertions of state
rather than have server cookie headers described in this document mixed with a
proliferation of different application-specific client state mechanisms.

-marc

--

Received on Friday, 14 June 1996 13:15:06 UTC