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:00 PM, David Morris <[e-mail]> wrote:
> On Wed, 24 Feb 2010, Adam Barth wrote:
>> On Wed, Feb 24, 2010 at 1:19 PM, David Morris <[e-mail]> wrote:
>> > I think we should instead stress (and document those that are known) that
>> > there are many opportunities to compromise the content of cookies
>> > including insertion of rogue cookies and/or removing valid cookies. Hence,
>> > the design of applications which depend on cookies should carefully
>> > consider the impact on application data integrity (and security) if
>> > the cookie mechanism is subverted. In this context, I use application
>> > in the classic sense of a set of computer software which delivers some
>> > form of service to people or other computer applications.
>>
>> We now have a fairly detailed Security Considerations section that
>> discusses all the security issues I know of with the cookie protocol.
>> If you know of things that aren't covered, please let me know and I'll
>> add them.
>>
>> I'm somewhat on the fence as to whether the general advice is helpful.
>
> My basic point, which reiterates what others have experessed, is that we
> can't forbid usage for which you don't have a better proposed alternative.

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.

> Appropriate general advice ... "Read and understand the Security
> Considerations" section and take the steps appropriate and necessary
> to reduce the risk to an acceptable level." Or something like that.

That seems like boilerplate that would need to be in every RFC.

Adam