Re: Issues with the cookie draft

dmk@research.bell-labs.com (Dave Kristol) wrote:
>Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
>  > [...]
>  > >[DMK]
>  > >I agree it's fuzzy, but RFC 2068 says nothing about transport security, so
>  > >it would be hard to be more specific.  I think we can agree, though, that
>  > >encryption is more secure than no encryption.  I don't want a cookie that
>  >                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
>  > >was originally encrypted to be returned to the server as cleartext.  So we
>  >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  > >*have* to say something here, and removing the statement would be wrong.
>  > >I invite alternative words that get the point across.
>  > 
>  > 	When we were field testing the cookie implementation in Lynx,
>  > it appeared the rule rather than the exception that cookies received
>  > via SSL connections, e.g., for banking transactions, did not include
>  > the Secure attribute.  Based on the wording in the RFC, under such
>  > circumstances the cookie could be sent as cleartext if the domain
>  > and path checks pass.   This didn't seem like a good thing to do
>  > (and you apparently agree 8-), so we arbitrarily tag such cookies
>  > as secure whether or not the Secure attribute was present in the
>  > Set-Cookie header.
>
>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.)

	I've never seen it used.


>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.
>
>  > [...]
>  > 
>  > 	One problem with this "better safe than sorry" implementation
>  > is that the site may be using the cookie solely for tracking, and may
>  > indeed want it included for both encrypted and unencrypted requests
>  > that pass the domain and path checks.  It's another can of worms, like
>  > the "unverifiable transactions" issue, that's ultimately attributable
>  > to lack of hard information to the UAs/users about the uses sites will
>  > make of cookies.   Though the "better safe than sorry" implementation
>  > seems preferable, IMHO, a clear justification for it should be included
>  > in the revision.
>
>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.


>  > 	I also agree that if the wording of the revision requires UAs
>  > to make relative judgements about the "level of security" offered by
>  > different encryption schemes without clear guidelines on how to make
>  > them, you'll be creating an implementation nighmare.
>
>As it is, it's a specification nightmare. :-)  It's probably a good bet
>that no one in ietf-tls would care to rate the relative level of security
>of the various encryption schemes.  But we can all probably agree that
>DES is better than cleartext or, say, rot13 or base64.

	The point, though, is that no formal ranking of encryption schemes
w.r.t. "security level" is likely to be forthcoming.  If a revision indicates
explicitly that encrypted cookies have an implied Secure, which we can see
from the recent discussion is "controversial" itself, added a ranking
requirement with no formal ranking mechanism surely will create a "no
possibility of broad consensus" dilemma.  Sigh...

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Wednesday, 19 March 1997 17:24:18 UTC