Re: Issues with the cookie draft

Dave Kristol <dmk@bell-labs.com> wrote:
>Yaron Goland wrote:
>>[...]
>> 2. Quotes & Responses:
>> 
>> Quote:
>> "When it sends a
>>      "secure" cookie back to a server, the user agent should use no less
>>      than the same level of security as was used when it received the
>>      cookie from the server."
>> 
>> Response:
>> What is greater or lesser security? Do we expect clients to record what
>> security they were using when they received the cookie and then, through
>> some as yet undefined mechanism, decide what "greater" or "lesser"
>> security than the original security mechanism means? This definition is
>> too fuzzy to be useful, I believe it should be removed.
>
>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.

	As things presently stand on the Web, what that really means
is that if a Set-Cookie header was received in reply to a request using
the https scheme, Lynx will include the cookie only in requests also
using the https scheme.  Furthermore, it seems unlikely that a server
would ever include the Secure attribute in a Set-Cookie header that was
not sent encrypted.  So, in effect, the presence or absence of the
Secure attribute becomes irrelevant (purely "advisory", or "confirmatory"
8-), and the actual variable is whether or not encryption was used.

	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.

	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.

				Fote

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

Received on Wednesday, 19 March 1997 14:08:16 UTC