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

[Adam Barth <[e-mail]>]

On Wed, Feb 24, 2010 at 2:43 PM, David Morris <[e-mail]> wrote:
> 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.

Okiedokes.  I'm not 100% convinced, but I've removed the General
Recommendations section from the draft.

Adam