Re: Issues with the cookie draft

Foteos Macrides wrote:
> >[DMK]
> >What I said in my email misrepresents what the spec. says.  I think your
> >"better safe than sorry" approach, though interesting and justifiable,
> >doesn't match the spec.
> 
>         Yes, the way we coded it does not "technically" match RFC2109.
> It's presently irrelvant for that spec, because the port contraint
> yields the same result for https versus http requests.   But that
> contraint was not part of the original cookie implementations, and
> what is actually encountered on today's Web.   My point is that,
> rightly or wrongly, we "arbitrarily" took the posture you stated in
> your reply to Yaron:
> 
>         "I don't want a cookie that was originally encrypted to be
>         returned to the server as cleartext."
> 
> i.e., that Secure should be implicit for encrypted cookies.  It seemed
> better to let the cookie handling "fail" under some circumstances than
> risk that happening (though it could "fail" anyway, at present, for
> UAs which adopted the RFC2109 port contraint when communicating with
> servers which do not expect to be contrained in this way).
> 
>         The reasoning was that under some circumstances, sending an
> originally encrypted cookie as cleartext might go beyond "privacy"
> risks to an actual security risk, and providers might not understand
> the issues adequately to include the Secure attribute in such cases,
> so don't *ever* take that risk.

On the other hand, I would figure that a site that was smart enough to know some
of its transactions need to be secured would also know that it has to label its
cookies as Secure.  Of course this could be hopelessly naive. :-)  I do see a real
value in allowing a secure site to send (by default) insecure cookies, which could
be use for various state tracking purposes, and which could be used in insecure
requests as well.

Dave Kristol

Received on Thursday, 20 March 1997 07:52:23 UTC