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

Koen Holtman wrote:
> There has never been a real consensus for 2109 or state-man-mec. 


At the time these documents were forwarded, it was my belief that
there was rough consensus for 2109 and, subsequently, state-man-mec.
The objections were to the mandatory default behavior necessary to
achieve the desired protections of the security considerations
section.

I believe it is still in the best interest of the Internet to publish
these documents, and that (unless there have been significant reversals
of previously strongly-held opinion) they still represent the
"rough consensus" of the community.

As for the specific comments:

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

This is covered in the last paragraph of section 2.2.1.

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

yes, that's the context. What's the problem?

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

You object to the word "marginal", but its usage in this context
is consistent with the intent and your statements. And the list
of advantages need not be listed exhaustively.

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

Well, its hard to equate the lack of a single flaw into "flawless",
but perhaps a "primarily", as in "it is not primarily a flaw in the
protocol itself" would satisfy your concern.

Received on Thursday, 15 July 1999 17:36:55 UTC