Subject: Re: Last Call: Applicability Statement for HTTP State Management to BCP

From: Dave Kristol <[email-masked]>
Date: Thu, 22 Jul 1999 17:27:53 -0400

Yaron Goland (Exchange) wrote (on June 24):
> 
> The following comments are regarding:
> http://www.ietf.org/internet-drafts/draft-ietf-http-state-man-mec-10.txt
>
> [Compliments to me omitted.]
> 
> OBJECTION:
> 
> The key failure in cookie security is authentication, the ability to know
> exactly with whom you are dealing. As we all know, domains can not provide
> this information which is the core of the cookie security problem. It will
> obviously take some time for a proper cookie authentication mechanism to be
> agreed upon and it is quite reasonable for people to seek some sort of
> interim solution which will provide at least some protection in the
> meantime.

I think this paragraph uses the terms "security" and "authentication" in
unusual ways, so I'd like to restate the objections as I understand them
and then address them.

Concerning "authentication", I don't believe in our discussions that we
ever worried about whether a cookie really came from the domain it
claimed to come from.  We discussed, instead, a related problem:  if a
client receives a cookie from example.com, to what hosts
should/must/must not the client return the cookie when it makes a new
request?  The current specification describes behavior that depends on
the Domain= attribute and its value.  The server is limited as to how
broadly the cookie may be distributed by the client in new requests, and
the decisions depend on domain names.  The intent of the restrictions is
to return cookies to one host or to a closely related set of hosts, so
they don't "leak" to unintended sites.  I think that's the "security" to
which Yaron refers.

I believe Yaron's objection, as he has voiced both to me privately and
on the relevant mailing lists, is that domain names are a rotten way to
make the decision.  On that we agree, although that's the most obvious
criterion available to us right now, and it is what Netscape's original
specification used.  It is possible to demonstrate cases where the
Domain rules for cookies on the one hand allow undesirable leakage and
on the other hand unduly restrict desirable behavior.  However, the
amount of leakage is no worse than with Netscape's specification for
cookies or with RFC 2109.

> 
> I do not believe that draft-ietf-http-state-man-mec-10.txt provides this
> interim solution. While the draft does provide some improvements in regards
> to the handling of cookies I personally do not believe that those
> improvements are sufficient to merit changing the existing client and server
> infrastructure. As such I believe that this draft should be blocked from
> progressing to proposed standard status until it can demonstrate a
> sufficiently high level of security to either qualify as a robust interim
> measure or until it provides a workable solution to the underlying problem.

I believe that the "improvements" that Yaron refers to would come from
another proprosal that has been languishing,
<http://www.ics.uci.edu/pub/ietf/http/draft-jaye-http-trust-state-mgt-00.txt>,
which describes what we have called "trusted cookies".  In short, the
idea is that a "trusted cookie" is cryptographically signed by a trusted
source, and, if the client trusts the source, it relaxes many of the RFC
2109 (and state-man-mec-10) restrictions, including the Domain
restrictions.  It has been my impression that correspondents on the
http-wg and http-state mailing lists agree that trusted cookies would be
layered on top of RFC 2109 and successors.

> 
> I realize that such judgments are completely subjective and am uncomfortable
> making the previous argument. I prefer arguments based on indisputable
> facts, but that doesn't appear possible here. On the positive side the
> specification is well written and certainly achieves its modest goals. No
> great harm will come to the internet community through its publication. I do
> believe, however, that it would be unfortunate for the IETF to lend its
> credibility to this specification in the specification's current state.

state-man-mec-10 is an incremental change from RFC 2109 that is meant to
correct shortcomings in the latter.  It reflects adherence to IETF
process and results from review of RFC 2109.  Therefore, yes, its goals
are modest.

[Specific technical comments addressed elsewhere.]

Dave Kristol

---

From: Dave Kristol <[email-masked]>
Date: Thu, 22 Jul 1999 17:27:53 -0400

Dave Kristol