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

[Achim Hoffmann <[e-mail]>]

[someone] wrote on 24.02.2010 09:13:
>> ...
>>> The point of confusion for me in:
>>>
>>> "The cookie protocol is NOT RECOMMENDED for new applications"
>>>

I don't see any problem with this sentence, if you look at the title of
this draft first.

As httpstate-cookie-04.txt already covers most objects my late response are
just my further explanations for the record.

----
Please apologies that this becomes a lengthy comment, but I try to summarize
some of the previous comments (without quoting explicitly).

Please remember that all my comments are made having "web application security"
in mind. This means secure web applications and its data and secure access for
users to them. The proper keywords, threats, weaknesses would be (without any
order):
  session hijacking, session fixation, session lockout, privilege esacalation,
  CSRF, and some more ...
IIRC it is not the focus of this draft to go into deeper explanations of them,
so I just leave these things uncommented.


As this draft is titled "HTTP State Management Mechanism"  and not for example
"HTTP user tracking gimmicks", the sentence  "The cookie protocol is NOT
RECOMMENDED ..." implies that the cookie protocol is meant for sessions. That's
what is also described in the Abstract and Introduction section. This sentence
is also in the "Security Considerations". So, there is nothing ambiguous when
reading from top to bottom. Adam's changes strengthen this:
> [[
>       The cookie protocol has many
>       historical infelicities that degrade its security and privacy.
> ]]
>
> How do folks feel about this related statement in Security Considerations:
>
> [[
>         <t>For applications that use the cookie protocol, servers SHOULD
>         NOT rely upon cookies for security.</t>
> ]]
>


Accoding some other objections:

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

Just because developers are unwilling (I'm not saying unable:) to use/implement
other mechanism, does not mean that they don't exist. Here are the well-known
alternatives (all defined back in the 90s last centuty;-):
  * Authentication protocol (manly Digest)
  * URL parameters
  * URL rewriting
  * form-based variables (aka hidden fields)
and if high security counts: a combination of at least two of the above.
We see that there're at least 3 HTTP and one HTML alternative (where the last
HTML method results in HTTP again). Means that they may be mentioned as they
are about HTTP too.

All these mechanisms (including cookies, which we're talking about) have their
own pros and cons, I won't explain them here for now, but can provide a
comprehensive comparsion of them. Some are covered in httpstate-cookie-04.txt
now.

If this draft states "cookie protocol is NOT RECOMENDED for sessions (due to
various security ambiguities)" then develpers, application architects and
decision-makers are hopefully reminded to think about better alternatives.
This would also encourage other organisations (PCI, OWASP, ...) to refer to
such a recomendation and then give practical suggestions and directives.
Let's make the wild wide web more secure.


> Security is about risk management and is never absolute.
Disagreed.
Security is also about threats, weakness, vulnerabilities, attacks.
If you combine these (for example in a formular) and map it to your impacts
(the real and theoretical ones) then you get a risk.
I'll stop here about the definitions, as it is off-topic here ...

> .. a SHOULD NOT statement is probabaly excessive.
Hmm, I'd say this statement gets up the nerv to tell people the real security
implications with the usage of the current cookie protocol ;-)


Hopefully above explains why such a sentence is important for security.


Achim