Re: [http-state] Whether to recommend the cookie protocol (was Re: I-D Action:draft-ietf-httpstate-cookie-04.txt)

[David Morris <[e-mail]>]

On Wed, 24 Feb 2010, Adam Barth wrote:

> 
> These statement don't forbid anything.  They're recommendations at the
> SHOULD level.  Is there a specific reason we can't recommend against
> something without providing an alternative?  For example, I don't know
> of any reasonable solutions to the integrity problems with cookies.
> Because of this issue, it's more or less impossible for a web
> application that relies on cookies for security to be secure against
> an active network attacker.
> 
> There's a lot of detail in the Security Considerations section.  The
> net-net, however, is that you shouldn't rely on cookies for security
> because their security properties are quite weak.

Security is about risk management and is never absolute. We can say here
are the risks we know about. It is not our responsiblity to perform the
risk cost assessment for a given application. This is the responsiblity
of the application owner.

Using SHOULD NOT is pretty strong in my experience. In this context,
it represents a risk management assesment for which we don't have
adequate knowledge. Making that kind of strong recommendation w/o
an alternative marginalizes the recomendation and perhaps the
whole document for at least some readers.