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

[ietf@ietf.org removed from distribution]

On Thu, 15 Jul 1999, Larry Masinter wrote:

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

Yes, exacly, there have always been objections to the default behavior of
the third party cookie filter, that was my main point.  The level of
consensus on the rest of the specification has been considerably higher.

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

It is my understanding that a lack of consensus on the security
considerations (in this case a lack of consensus on how much privacy is
needed by default) implies a lack of consensus on the whole specification.

> 
> As for the specific comments:

Note: these are my specific nitpicks of iesg-http-cookies.  My main
objection to publishing the current draft as a BCP lies somewhere else,
see my original message.

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

The first SHOULD NOT in that section is fairly definite, and I am mainly
objecting to that one.  The second SHOULD NOT weakens it, and one can
indeed argue that the last paragraphs gives even more wiggle room, even if
it does not contain any uppercase keywords.  A bit of rebalancing of
SHOULDs will probably resolve my problem. 
 
> > - (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?

The section implies that Content-Location can be used to maintain state on
its own in some way, outside the context of redirects.  In fact, I just
recall that HTTP redirection uses 'location', not 'content-location', so
really content-location has little to do with any currently feasible
method of maintaining state. 

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

I am suggesting a way to improve the presentation.  "marginal" does not
sound right to me, even if you believe it to be consistent with what 
I want.

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

I said that I believe it _is_ a flaw in the protocol, your proposed
restatement would not work to satisfy my concern, which is about weakening
the level of what is acceptable in an ietf standards track protocol. 

Koen.

Received on Wednesday, 21 July 1999 15:11:16 UTC