Re: Issues with the cookie draft

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.)
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.
  > 
  > 	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.

Dave Kristol

Received on Wednesday, 19 March 1997 14:37:38 UTC