Subject: [apps-discuss] Apps area review of draft-ietf-httpstate-cookie-19

From: Lisa Dusseault <[email-masked]>
Date: Sun, 5 Dec 2010 10:05:30 -0800

Hi Adam and others,

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Document: draft-ietf-httpstate-cookie-19
Title: HTTP State Management Mechanism
Reviewer: Lisa Dusseault
Review Date: Dec 5, 2010
IETF Last Call Date: 2010-11-29
IESG Telechat Date: 2010-12-16]
Summary: I recommend this document for publication.  The document
alone is quite valuable, and the actions to register headers and mark
other documents as historic makes it even more useful to the Internet
community. I also found this document had strong investigation,
discussion and reviews in its history.

Major Issues: None
Minor Issues:
Section 3. "Origin servers can send a Set-Cookie response header with
any response.".  Do we happen to know if it's more common for user
agents to handle, or ignore Set-Cookie response headers on error
responses?  I'd be surprised if user-agents do handle them including
on 500-level, 400-level and particularly on a 100 Continue response,
but I haven't tested it.  Is it part of your tests?  So while this
statement is factual, it might not help servers much.  If my
assumption about some clients ignoring the header on some classes of
responses is correct, I would add that information to the document in
a non-normative sentence.

Section 4.  As a matter of taste, my choice would be to make it even
more clear that third-party cookie protections erected by user agents
cannot provide the desired protection from cooperating servers.  E.g.
"No limitations on cookie use can prevent cooperating servers from
injecting identifying information in dynamic URLs."

Thank-you,
Lisa Dusseault

---

From: Adam Barth <[email-masked]>
Date: Sun, 5 Dec 2010 12:50:50 -0800

On Sun, Dec 5, 2010 at 10:05 AM, Lisa Dusseault
<[email-masked]> wrote:
> but I haven't tested it.  Is it part of your tests?

I haven't tested those cases specifically.  I suspect user agents
process Set-Cookie headers for 500-level and 400-level responses.  I'm
less sure about 100-level responses.

> So while this

I'll test this and update the document accordingly.

> injecting identifying information in dynamic URLs."

Sure.  I wasn't exactly sure where you'd like this text to appear.  We
don't seem to mention third-party cookies in Section 4.  In Section 5,
we mention them three times.  We also discuss them in the privacy
considerations.

We now have the following text in the Privacy Considerations section:

          In particular, two collaborating
          servers can often track users without using cookies at all by
          injecting identifying information into dynamic URLs.

Thanks,
Adam