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

"Marc Salomon" <> wrote:
  > 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
No.  An adversary could simply add itself to the list of Domains it
intercepts.  A subsequent visit to the adversary's site would disclose
the Cookie.
  > constructed so that only friends could its verify its validity over a small
  > Max-Age, the threat of MITM could be minimized.
Who decides who are "friends"?  A special-purpose client could do so,
but I don't think that's what you're thinking of.  And once the origin
server sends off the Cookie, it can't prevent the MITM changes.
  > > 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?

The specification is vendor-neutral in the sense that other vendors can
implement to it and produce interoperable versions.  It's somewhat
different from NS's original implementation to improve its privacy
aspects and to tighten up the specification.

Is it perfect or complete?  Surely not.  (For one thing, the definition
of "complete" keeps changing.)  But there's value in getting out a
consensus specification sooner, rather than later.  Just as with
HTTP/1.1, it's reasonable to expect the cookie spec. to evolve.
  > 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?
For all I know, vendors will do just that.  Implementations without
specifications are much more useful than the reverse.

Dave Kristol

Received on Friday, 14 June 1996 15:01:30 UTC