Re: [http-state] Welcome to http-state

Agreed that cross-scheme clobbering is historically allowed by user
agents. However, clobbering a cookie is different than causing a cookie
to be evicted. The former impacts the integrity of the cookie while the
latter impacts cookie availability. The purpose of an anti-clobber
mechanism is to protect the integrity of the Secure cookie. To be
effective, the user agent must treat cookies of the same origin
(domain-match + path-match) and NAME distinctly if their schemes differ.
This implies adding a scheme-match check to the user agent. I see such a
mechanism as a defense in depth measure - akin to HttpOnly. I'm
interested in hearing what everyone thinks about the utility of such a
control. 

Blake

-----Original Message-----
From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org]
On Behalf Of Adam Barth
Sent: Monday, January 12, 2009 12:00 PM
To: Discuss HTTP State Management Mechanism
Subject: Re: [http-state] Welcome to http-state

On Mon, Jan 12, 2009 at 11:51 AM, Blake Frantz <bfrantz@cisecurity.org>
wrote:
> 1. While RFC2109 and draft-pettersen-cookie-v2-03.txt define the
> 'Secure' cookie-av to advise the user-agent against sending the cookie
> over an insecure transport they do not define the desired user-agent
> behavior for cross scheme writing. For example, http://foo.bar
> clobbering a cookie set by https://foo.bar.

Historically, cross-scheme clobbering has been allowed by user agents
because it is impossible to prevent with a bounded amount of storage
(due to eviction of Secure cookies).

Adam
_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state