Subject: Fwd: I-D Action:draft-pettersen-cookie-v2-03.txt

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 03 Nov 2008 23:47:57 +0100

------- Forwarded message -------
From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-pettersen-cookie-v2-03.txt
Date: Mon, 03 Nov 2008 23:15:01 +0100

A New Internet-Draft is available from the on-line Internet-Drafts  
directories.

	Title           : HTTP State Management Mechanism v2
	Author(s)       : Y. Pettersen
	Filename        : draft-pettersen-cookie-v2-03.txt
	Pages           : 31
	Date            : 2008-11-03

This document specifies a way to create a stateful session with
Hypertext Transfer Protocol (HTTP) requests and responses.  It
describes three HTTP headers, Cookie, Cookie2, and Set-Cookie2, which
carry state information between participating origin servers and user
agents.  The method described here differs from both Netscape's
Cookie proposal [Netscape], and [RFC2965], but it can, provided some
requirements are met, interoperate with HTTP/1.1 user agents that use
Netscape's method.  (See the HISTORICAL section.)

This document defines new rules for how cookies can be shared between
servers within a domain.  These new rules are intended to address
security and privacy concerns that are difficult to counter for
clients implementing Netscape's proposed rules or the rules specified
by RFC 2965.

This document reflects implementation experience with RFC 2965 and
obsoletes it.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Amit Klein <[email-masked]>
Date: Sun, 09 Nov 2008 22:36:09 +0200

Hi

Not sure if this is the right forum to ask questions and/or suggest 
improvements. If it isn't - I beg forgiveness and guide ;-)

To the point:

Section 2 defines "path-matching" as:
"For two strings that represent paths, P1 and P2, P1 path-matches P2 if 
P2 is a prefix of P1 (including the case where P1 and P2 string- compare 
equal). Thus, the string /tec/waldo path-matches /tec."

And I don't see any requirement in the document for the path to end with 
slash (neither in $Path, nor in Path).

So if I understand correctly, this means that /technology path-matches 
/tec. Is this the desired behavior? I can think of operability issues 
(e.g. two applications residing on the same server, one is called /app 
and the other /app2). There may also be security implications (though in 
general, I don't believe in per-path security: 
http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html).

BTW - typo? in section 3.3.2:
"A Set-Cookie2 from a path /example1/example1 for SubPath=exam will be 
accepted for the path /example/exam" - I think this should be:
"A Set-Cookie2 from a path /example1/example1 for SubPath=exam will be 
accepted for the path /example1/exam"

Thanks,
-Amit

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sun, 09 Nov 2008 22:55:13 +0100

Hello Amit,

> /tec. Is this the desired behavior? I can think of operability issues

You understand correctly, and that is precisely what Netscape originally  
wanted:

      The path "/foo" would match "/foobar" and "/foo/bar.html".

> and the other /app2). There may also be security implications (though in

Cookie specs released after Netscape's specifically require the client to  
send the $Path attribute with cookies that set a path, so that the  
receiving application can decide if the received cookie is one that it  
wants to look at.

It is, however, up to the site owner to choose appropriate cookie  
namespaces and resource namespaces.

We have seen a number of sites that actually end up having multiple  
cookies with the same name, but different paths and/or domains, causing  
problems. A prime example of this is amtrak.com's online booking system.

The reason I have chosen to discard the Path attribute in my proposed  
update is that it allowed users sharing the same host to interfere with  
each other.

The new SubPath attribute allows a site designer to further *restrict* the  
cookie's distribution (old version was to *increase* distribution), within  
the default path of the cookie (which is to and including the rightmost  
"/"; which means that a siteowner should ensure that "/user" is  
automatically redirected to "/user/"). The only way a cookie can be  
distributed to all paths on the server is by having a resource in the root  
set it (previously, a malicious script deep within the hierarchy could set  
such a wide distribution cookies).

Similar restrictions are also introduced for domain wide distribution of  
cookies; a host machine at the top of the domain must set such cookies,  
not one 5 levels down, as is done on some online services.

> accepted for the path /example1/exam"

Thanks, fixed.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Amit Klein <[email-masked]>
Date: Mon, 10 Nov 2008 00:17:17 +0200

Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> update is that it allowed users sharing the same host to interfere 
> with each other.

In which case you may want to rephrase the SubPath definition in section 
3.2.2, as it does mention "Path attribute".

---

From: "Amit Klein" <[email-masked]>
Date: Tue, 11 Nov 2008 10:04:20 +0200

Hi again,

With respect to section 8.1 (security considerations - protocol
design), particularly "a server can only share cookies with resource
in subfolders of the default path derived from the request-URI", I
would like to draw your attention to the many ways "path security" can
be bypassed:

http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html

As such, I would recommend not to state that path separation of
cookies has (above marginal) security value.

Thanks,
-Amit

On Tue, Nov 4, 2008 at 12:47 AM, Yngve N. Pettersen (Developer Opera