[http-state] The Domain attribute (was Re: I-D Action:draft-ietf-httpstate-cookie-20.txt)

Adam Barth <ietf@adambarth.com> Thu, 06 January 2011 20:48 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F3F3A6DF5 for <http-state@core3.amsl.com>; Thu, 6 Jan 2011 12:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.68
X-Spam-Level:
X-Spam-Status: No, score=-3.68 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtI5d7KWunNY for <http-state@core3.amsl.com>; Thu, 6 Jan 2011 12:48:51 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7A5423A6CFF for <http-state@ietf.org>; Thu, 6 Jan 2011 12:48:50 -0800 (PST)
Received: by fxm9 with SMTP id 9so16511488fxm.31 for <http-state@ietf.org>; Thu, 06 Jan 2011 12:50:56 -0800 (PST)
Received: by 10.223.83.201 with SMTP id g9mr959710fal.140.1294347056764; Thu, 06 Jan 2011 12:50:56 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id z1sm5976734fau.45.2011.01.06.12.50.55 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 12:50:56 -0800 (PST)
Received: by iwn40 with SMTP id 40so17680013iwn.31 for <http-state@ietf.org>; Thu, 06 Jan 2011 12:50:54 -0800 (PST)
Received: by 10.231.156.1 with SMTP id u1mr8536135ibw.52.1294347054440; Thu, 06 Jan 2011 12:50:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.11.140 with HTTP; Thu, 6 Jan 2011 12:50:24 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 06 Jan 2011 12:50:24 -0800
Message-ID: <AANLkTinK+2sfe4UZLKF5G0MLrQ6es2BfTHwtT769sgSM@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: [http-state] The Domain attribute (was Re: I-D Action:draft-ietf-httpstate-cookie-20.txt)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jan 2011 20:48:52 -0000

On Thu, Jan 6, 2011 at 7:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> Adam,
>
> In the RFC 2109, the "domain" attribute is optional.  Specifically, it says:
>
>   Domain=domain
>      Optional.  The Domain attribute specifies the domain for which the
>      cookie is valid.  An explicitly specified domain must always start
>      with a dot.
>
>  It also defined a default:
>   Domain Defaults to the request-host.  (Note that there is no dot at
>          the beginning of request-host.)

Right.

> I found this in the -20 draft:
>
> 4.1.2.3:
>   If the server omits the Domain attribute, the user
>   agent will return the cookie only to the origin server.
>
>      WARNING: Some existing user agents treat an absent Domain
>      attribute as if the Domain attribute were present and contained
>      the current host name.  For example, if example.com returns a Set-
>      Cookie header without a Domain attribute, these user agents will
>      erroneously send the cookie to www.example.com as well.
>
> If I received a cookie without a domain from test.example.com, I would
> assume the cookie's domain is "test.example.com".  The wording above
> confuses me a little, as I would bind the cookie to the host I accessed.
> The first sentence in the WARNING seems like what I should do, but the
> example presented is not the origin server or the "current host name".  I
> agree that it would be an error for a browser to assume a larger domain
> scope than just the single host being accessed.  But, I would think that
> absence of or an empty string for "Domain" would be bound only to the server
> being accessed.  I believe that is the intent, as stated in other sections,
> but the warning text seems to suggest otherwise when I read it.

Right, the issue is that some browsers forget to set the host-only
flag on the cookie if you omit the Domain attribute.  That causes the
cookie to be returned to the origin server as well as all subdomains
of the origin server's host name.

> In Section 5.2.3, this text appears:
>   If the attribute-value is empty, the behavior is undefined.  However,
>   user agent SHOULD ignore the cookie-av entirely.
>
> Why would the behavior be undefined?  Why would these not be treated
> identically?
> Set-Cookie: mycookie=myvalue; path=/
> Set-Cookie: mycookie=myvalue; path=/; domain=

It's undefined because different implementations do different things
and I didn't have the energy or the inclination to beat them up on
this point.  They should do what the document suggests, but it's not
the end of the world fi they don't.

> Why isn't an empty string a valid value?  I ask, because we assign an empty
> value internally.  In 5.3, paragraph 4, we have:
>
>   4.   If the cookie-attribute-list contains an attribute with an
>        attribute-name of "Domain":
>
>           Let the domain-attribute be the attribute-value of the last
>           attribute in the cookie-attribute-list with an attribute-name
>           of "Domain".
>
>        Otherwise:
>
>           Let the domain-attribute be the empty string.
>
> So, this does suggest "domain=" would be the same as absence of the domain
> parameter, no?

Well, the complexity actually arises when the server provides multiple
Domain attributes, some of which are the empty string.  Which one
actually controls the result varies.

The rules are written such that if you follow them, you get reasonable
behavior that matches practice.  There's also some wiggle room to in
this extreme corner case (multiple attributes, one of which is the
empty string).  We could nail that issue down, but it didn't seem
worth the hassle.

> Paragraph 6 then explains that in such cases, the domain is
> assigned to "the canonicalized request-host", which is consistent.
>
> So, any reason why the Domain a/v syntax isn't this?
> domain-value      = <subdomain> | ""

Just because it's nonsense semantically and an interoperability
sandtrap.  If you'd like to use the empty string, just omit the Domain
attribute instead.  Your life and everyone else's life will be happier
for it.

Adam


>> -----Original Message-----
>> From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org]
>> On Behalf Of Internet-Drafts@ietf.org
>> Sent: Sunday, December 19, 2010 2:00 PM
>> To: i-d-announce@ietf.org
>> Cc: http-state@ietf.org
>> Subject: [http-state] I-D Action:draft-ietf-httpstate-cookie-20.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the HTTP State Management Mechanism Working
>> Group of the IETF.
>>
>>
>>       Title           : HTTP State Management Mechanism
>>       Author(s)       : A. Barth
>>       Filename        : draft-ietf-httpstate-cookie-20.txt
>>       Pages           : 44
>>       Date            : 2010-12-19
>>
>> This document defines the HTTP Cookie and Set-Cookie header fields.
>> These header fields can be used by HTTP servers to store state (called
>> cookies) at HTTP user agents, letting the servers maintain a stateful
>> session over the mostly stateless HTTP protocol.  Although cookies have
>> many historical infelicities that degrade their security and privacy,
>> the Cookie and Set-Cookie header fields are widely used on the
>> Internet.Editorial Note (To be removed by RFC Editor)
>>
>> If you have suggestions for improving this document, please send email
>> to <mailto:http-state@ietf.org>.  Suggestions with test cases are
>> especially appreciated.  Further Working Group information is available
>> from <https://tools.ietf.org/wg/httpstate/>.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-httpstate-cookie-20.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.
>
>