W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Issues with the cookie draft

From: David W. Morris <dwm@xpasc.com>
Date: Wed, 19 Mar 1997 15:13:05 -0800 (PST)
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SOL.3.95.970319144122.26025B-100000@shell1.aimnet.com>
To: http-wg@cuckoo.hpl.hp.com


On Wed, 19 Mar 1997, Dave Kristol wrote:

> Well, I mis-spoke, but your point is an interesting one.  Actually there
> are a couple of interesting issues.
> 
> 1) Is "Secure" implicit?
> 2) If not, then for example sending a cookie for an http: request after
> receiving it from an https: request means we're violating the constraint
> that the cookie should only be sent back to the same port it came from.
> 
> What we were *trying* to do was more or less document what Netscape did
> originally.  So,
> 
> 1) "Secure" was a hint.  (I wonder if anyone actually uses it.)
> 2) A cookie marked as "Secure" should only go out securely.  Although there
> was no such requirement, one presumes it was received securely!
> 3) A cookie not marked as "Secure" could go out in other requests.  This
> would appear to conflict with the "to same port" constraint I added in
> response to someone's comment.

I think the same port requirement makes no sense unless the set-cookie
included a port specification.  After all, allowing a cookie to be
shared between x.y.com and w.y.com which are likely to be two machines
but not between x.y.com:80 and x.y.com:8080 which most likely will be
one machine and under a tighter span of control seems like a misdirected
concern. Hence, I would propose removing the port match requirement.

Following that, I would argue that sharing cookies between http and https
is very desireable and as long as the other verifications requirements are
met, doesn't create additional exposures.

My basic premise is that SSL transactions are expensive in CPU and will
also impact raw wire transfer time because MODEM/router hop level
compression will be almost useless. Given that assumption, assume the
following application design:

a) SSL post of a login request
b) Response includes a session ID cookie NOT marked secure
c) The user's next several interactions accumulate a list of things to
   purchase.
d) The user clicks CHECKOUT which brings a response which includes
   a secure POST of a credit card or PIN number to confirm the purchase.

In this example, the cookie is issued in a secure response, carried  in
multiple unsecure transactions and finally used in another secure
transaction.

OR, perhaps step a isn't needed and the cookie is issued in an unsecure
connection, used to accumulate  the shopping basket and finally returned
on a secure connection to complete the transaction.  In either case,
substantial system resources are saved by limiting the duration of the SSL
'session'.

Dave Morris
Received on Wednesday, 19 March 1997 15:13:59 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:32 EDT