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

From: Adam Barth <[email-masked]>
Date: Tue, 23 Feb 2010 18:55:14 -0800

On Tue, Feb 23, 2010 at 9:10 AM, Anne van Kesteren <[email-masked]> wrote:
> On Tue, 23 Feb 2010 17:15:04 +0100, <[email-masked]> wrote:
>> The cookie protocol has many
>> historical infelicities and should be avoided for new applications of
>> HTTP.
>
> What exactly does this mean?

It means that we don't think new applications of HTTP (e.g., SIP)
should use the cookie protocol.  Cookies have caused significant
security problems for the web.  For new applications, it's probably a
good idea to use another state management mechanism.

> There's no suitable replacement for cookies
> available currently so giving this advice seems a bit premature, but maybe I
> misunderstand what it says.

Hopefully we'll create a suitable replacement in phase two.  If not,
necessity is the mother of invention...

On Tue, Feb 23, 2010 at 9:15 AM, Blake Frantz <[email-masked]> wrote:
> Similarly, the top of section '7.1 General Recommendations' states:
>
> "The cookie protocol is NOT RECOMMENDED for new applications".
>
> This statement may require the same clarification as the one noted by Anne.

What clarification do you have in mind?  Keep in mind that we're
writing this document for the long term.  Just because we don't have
an alternative in mind doesn't mean we won't have better options in
the future.

Would you really recommend that new applications of HTTP use cookies?

Adam

---

From: Blake Frantz <[email-masked]>
Date: Tue, 23 Feb 2010 21:23:25 -0600

> -----Original Message-----
> From: Adam Barth [mailto:[email-masked]]
> Sent: Tuesday, February 23, 2010 6:55 PM
> To: Anne van Kesteren; Blake Frantz
> Cc: http-state
> Subject: Whether to recommend the cookie protocol (was Re: [http-state]
> I-D Action:draft-ietf-httpstate-cookie-04.txt)
> 

The point of confusion for me in:

"The cookie protocol is NOT RECOMMENDED for new applications"

was the ambiguity of the word "application". Until you mentioned SIP, I interpreted "application" as a "web application" that I would interact with via my browser. Perhaps the following will help prevent other readers from doing the same as I did:

"The cookie protocol is NOT RECOMMENDED for maintaining state in new protocols that operate over HTTP."

B

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Feb 2010 19:29:08 -0800

> "The cookie protocol is NOT RECOMMENDED for maintaining state in new protocols that operate over HTTP."

Done (with "use" in place of "maintaining state").

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 21:04:46 -0700

> good idea to use another state management mechanism.

Could you explain the sense in which SIP is an application of HTTP? I'm
trying to understand which of the following best captures what you are
saying:

1. Non-web technologies SHOULD NOT use cookies but instead SHOULD define
their own application-specific methods for state management.

2. Non-web technologies that define bindings to HTTP (e.g., the HTTP
binding for XMPP defined in [BOSH]) SHOULD NOT use cookies even within
such a binding but instead SHOULD define their own application-specific
methods for state management.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Feb 2010 20:11:11 -0800

On Tue, Feb 23, 2010 at 8:04 PM, Peter Saint-Andre <[email-masked]> wrote:
> Could you explain the sense in which SIP is an application of HTTP?

Oh, I could be using the wrong terminology here.  How would you
describe the relation between SIP and HTTP?

> I'm

I'm not sure what the difference between these options is.  I'm not
sure we should recommend application-specific state management.
Instead, we should aim for a general-purpose HTTP state management
mechanism that doesn't suck (in phase two, of course).

Adam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Feb 2010 09:13:10 +0100

On 24.02.2010 04:29, Adam Barth wrote:
> ...
> ...

As others have stated, without a definition of "new protocol that 
operates over HTTP" this doesn't work. It's also problematic to put 
BCP14-requirements on spec writers :-)

For instance, do you consider WebDAV or AtomPub "protocols that operate 
over HTTP"? If they

Don't get me wrong; it would be good to discourage use of cookies, but 
this would need to come with more text, outlining the alternatives.

Best regards, Julian

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 24 Feb 2010 00:32:15 -0800

> necessity is the mother of invention...

I look forward to the more exciting XHTML2 phase of our Working Group,  
but perhaps we should wait until we actually have a good replacement  
before we tell people to stop using what works today.

> Would you really recommend that new applications of HTTP use cookies?

Doesn't "NOT RECOMMENDED" effectively give a SHOULD-level requirement  
not to use any of the spec we are developing, and furthermore one that  
is likely to be almost totally ignored? That seems like two good  
reasons to omit that statement, at least if it is framed as a  
conformance statement.

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Feb 2010 09:26:08 -0800

On Wed, Feb 24, 2010 at 12:13 AM, Julian Reschke <[email-masked]> wrote:
> As others have stated, without a definition of "new protocol that operates
> over HTTP" this doesn't work. It's also problematic to put
> For instance, do you consider WebDAV or AtomPub "protocols that operate over
> HTTP"? If they
>
> Don't get me wrong; it would be good to discourage use of cookies, but this
> would need to come with more text, outlining the alternatives.

On Wed, Feb 24, 2010 at 12:32 AM, Maciej Stachowiak <[email-masked]> wrote:
> I look forward to the more exciting XHTML2 phase of our Working Group, but
> perhaps we should wait until we actually have a good replacement before we
> tell people to stop using what works today.

:)

> Doesn't "NOT RECOMMENDED" effectively give a SHOULD-level requirement not to
> use any of the spec we are developing, and furthermore one that is likely to
> be almost totally ignored? That seems like two good reasons to omit that
> statement, at least if it is framed as a conformance statement.

Ok.  I've removed this requirement.  I've also changed the sentence in
the abstract to

[[
      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>
]]

Adam

---

From: David Morris <[email-masked]>
Date: Wed, 24 Feb 2010 13:19:50 -0800 (PST)

>       historical infelicities that degrade its security and privacy.

Better, but I think 'infelicities' is not a common word and its use would 
make the docuemnt harder to read.

>         NOT rely upon cookies for security.</t>

Given that we are documenting an existing protocol, a SHOULD NOT statement
is probabaly excessive.

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.

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Feb 2010 13:28:05 -0800

> make the docuemnt harder to read.

That sounds like an editorial decision.  On a previous thread someone
mentioned that they happened to like this word.  :)

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

Adam

---

From: David Morris <[email-masked]>
Date: Wed, 24 Feb 2010 14:00:24 -0800 (PST)

> mentioned that they happened to like this word.  :)

I don't dislike the word, after I looked it up, I recognize it fits 
Consider this editorial advice ... don't use words that aren't commonly 
known to your english speaking audience. The remainder of the 
international audience won't have a clue and will either have to look the 
word up or choose to not accurately understand what you have written.

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

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.

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Feb 2010 14:11:35 -0800

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

> 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

---

From: David Morris <[email-masked]>
Date: Wed, 24 Feb 2010 14:43:44 -0800 (PST)

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

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Feb 2010 14:50:33 -0800

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 16:52:06 -0700

> describe the relation between SIP and HTTP?

As far as I can see, there is none, which is why I'm confused. SIP is a
non-web, non-HTTP technology. The same is true of XMPP. Now, some
non-web, non-HTTP technologies have bindings to HTTP, often achieved
using long polling (this is true of XMPP, whose "BOSH" technology is
used to emulate TCP connections via long polling over HTTP). In that
case the HTTP binding might use cookies but typically does not. But
natively a technology like SIP or XMPP is utterly distinct from HTTP.

> I'm not sure what the difference between these options is. 

It might be a distinction without a difference. See above on HTTP
bindings vs. native modes for technologies like SIP and XMPP.

> I'm not

Right, but are we aiming for a general-purpose state management
mechanism or a general-purpose *HTTP* state management mechanism? If the
former, we're designing for SIP and XMPP and FTP and Gopher and SMTP and
HTTP and any other application-level technology. If the latter then the
job is much easier (though still hard).

Do we really need to say anything about non-HTTP technologies in an
informational document on HTTP state management? It's not clear to me
that we do.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Feb 2010 16:04:14 -0800

I didn't understand very much of your message, probably because I'm
ignorant of the relevant technologies and their associated social
conventions.  In any case, the subject is moot because the text you're
arguing against has been removed.

Kind regards,
Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 17:05:19 -0700

> arguing against has been removed.

Well that's even clearer, then. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Achim Hoffmann <[email-masked]>
Date: Sun, 28 Feb 2010 13:08:58 +0100

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

> 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