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

On Wed, 23 Jun 1999, The IESG wrote:

> 
> The IESG has received a request from the IETF Steering Group Working
> Group to consider Applicability Statement for HTTP State Management
> <draft-iesg-http-cookies-00.txt> as a BCP.
> 
> The IESG will also consider HTTP State Management Mechanism
> <draft-ietf-http-state-man-mec-10.txt> as a Proposed Standard.
[...]



Dear IESG,

First, let me join in thanking David Kristol for the amount of work done. 
It would be nice to declare victory, publish RFCs, and move on.  However
things are not that simple. 

I believe that the current cookie situation on the internet is
seriously broken as far as privacy is concerned.  However, I don't
believe that moving the above two drafts to BCP and proposed standard
will benefit the internet community.  I would prefer it if either

- the IESG did nothing and let the two drafts disappear
  silently from the internet draft repository, or

- state-man-mec were moved to experimental, superseding 2109,
  with iesg-http-cookies disappearing silently.

Basically state-man-mec is too controversial to end up on the standards
track.  The controversy surrounding the state management work had some
good effects, so I don't feel that the effort on it was wasted, but going
on to publish proposed standards would be a bit strange given all the
controversy. 


* On cookies and the IETF

I believe that the cookie situation that we live with now would
benefit from both a) some tight spec writing and b) a lot of social
engineering.  I don't expect many people to disagree to a).  The
Netscape cookie specification has a lot of vague parts and it would be
nice to have a better spec that clears them up.  Point b) is more
contentious: there are people out there who believe that the current
cookie situation is perfectly OK.  From my state management
discussions with them in e-mail over the last few years, I conclude
that their number is significant.  These are not just one or two
disagreeable individuals who can be ignored in declaring an IETF
consensus.

What we really have here is a political struggle between the
'commercial complex' which wants to obtain and resell a lot of
privacy-related information from end users as a means of supporting
content, and a 'consumer complex' which believes that this way of
supporting content is either inherently wrong, or that the consumer is
getting far too little value out of the current deal.

I believe that this political struggle cannot be resolved through the
IETF consensus process.  (It might be possible to silently complete an
IETF last call without anybody in the 'commercial complex' noticing,
but that won't resolve anything.)

What the IESG and IETF can feasibly do with respect to cookies:

1. the IESG could release policy statements with respect to cookies,
   which are clearly independent from the IETF consensus/standards
   process (draft-iesg-http-cookies-00 is not very good as such a
   statement, see below)

2. the IETF can write an informational spec which tightens up the
   definition of Netscape cookies, but which does not add any new
   security/privacy restrictions beyond those in the
   Netscape spec (2109/state-man-mec is not such a spec)

3. the IETF could try to change the playing field of the political
   struggle by developing credible specifications of *optional*
   protocol-level 'cookie filters' to enhance privacy, or privacy
   negotiation mechanisms.  (2109/state-man-mec contains the
   `unverifiable transaction' or 'third party cookie' mechanism, which
   is an example of what I mean, by a 'cookie filter', though the use
   of it is not optional in these specs, the filter should be switched
   on by default.)  Of course a number of browser implementers already
   provide various forms of cookie filters, and this is a good thing.
   Public specifications of such filters would be very valuable to the
   designers of stateful sites, to ensure that their sites will keep
   working, or fail gracefully, if certain filters are switched on or
   off.

Actions 2. and 3. would require significant new editorial work, it is
unclear whether we would see it being done even if there is a broad
feeling that this is the way to go.  In any case both 2. and 3. are
compatible with dropping state-man-mec from the repository or moving
it to experimental.


* Comments on draft-ietf-http-state-man-mec-10.txt:

There has never been a real consensus for 2109 or state-man-mec.  The
main breaking point has always been that the draft specifies that the
'cookie filter' for third party cookies (cookies in unverifiable
transactions) should be switched 'on' by default.  Basically there is
a large group of web advertisers and people depending on web
advertising who believe that the filter should be 'off' by default.
Most significantly, the two major browser implementors believe (or I
should say their representatives implied this at one point, and I have
not seen a reversal since) that their interests are best served by
providing implementations which do not filter out third party cookies
by default.

Pushing state-man-mec onto the standards track without a good IETF
consensus may be something the IESG can 'legally' do (I would not
know), but I don't see how the internet community would be served by
this.

Yaron Goland commented recently that state-man-mec has too few
improved elements over the old Netscape cookies to warrant a
changeover of the infrastructure.  I agree to some extent: I would say
that the changes to browser implementations and site policies that I
want could be made without changing the Netscape cookie wire protocol.

Yaron also said that:
|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.

I'm not sure if Yaron is referring to the need for some kind of
cross-domain identification scheme, or to the need for signed
certificates or similar IDs.  In either case I disagree: the key
failure in cookie security is inadequate support and defaults for user
privacy in most deployed browsers.  Adding more authentication to the
wire protocol won't solve this core problem.


* Comments on draft-iesg-http-cookies-00.txt:

My main problem with iesg-http-cookies is that it sets out to define a
standard that does not have an RFC number but is in stead is made up
of two RFCs on different tracks.  Some quotes:

|Uses in the latter category should be considered violations of the
|standard, even though the actual protocol implementations may conform
|to the standard.  This memo, along with RFC- XXXX, is considered part
|of the HTTP State Management protocol specification.

|The following uses of HTTP State Management are deemed inappropriate
|and a violation of the standard:

iesg-http-cookies can be read as a kind of appendix that introduces
new MUST-level requirements into the standards-track IETF
state-man-mec wire protocol specification through the back door.
While this is not a very friendly interpretation, it is a plausible
one.  As such, iesg-http-cookies exposes the IESG and IETF to the risk
of some rather effective attacks should the mass media flamewar over
cookies flare up again, attacks which could lower the credibility of
the whole IETF process.

I am not against the IESG entering the cookie privacy debate,
especially if it is on the side that I belong to.  But if it does,
much more care should be taken to separate IESG policy statements from
the IETF consensus process.  Also a pure policy statement, if made,
should apply to both Netscape and state-man-mec cookies.

Comments on details:

- I believe that the '2.2.1. Leakage of Information to Third Parties'
requirements in iesg-http-cookies are good practice.  However, I think
that the '2.2.1. Use as an Authentication Mechanism' requirements go
too far: for some cases where the security concerns of authentication
are minor and the usability concerns are major, I consider the use of
cookies for authentication to be a valid engineering solution.

- (section 2:) The HTTP Content-Location header field cannot currently
be used in a scheme to maintain state, except when it is part of a
HTTP redirect.

- (section 2:) I do not agree to the statement that state management
represents a 'marginal (but still useful) increase in functionality
over ordinary HTTP and HTML.'  The increase is not marginal for people
who want to build reliable services that maintain state.  A major
advantage of cookies not mentioned in section 2 is that cookie state
is insensitive to users navigating the site using the 'back' button or
history functions.

- (section 3:) 'While such exposure is possible, this is not a flaw in
the protocol itself'.  It _is_ a flaw in the protocol itself, one that
was inherited from Netscape cookies.  Other less flawed state
management protocols would have been possible, but were pre-empted by
cookies.  If state-man-mec is called flawless in an IESG BCP document,
this implies to me that new protocols with similar flaws would have a
good chance of passing an IETF/IESG security considerations review,
which they clearly should not.

Koen.

Received on Wednesday, 21 July 1999 15:13:22 UTC