Re: [http-state] Gen-ART LC review of draft-ietf-httpstate-cookie-18

[Peter Saint-Andre <[e-mail]>]

Yes, thanks!

Adam, if you submit a revised I-D based on Richard's review I will put
this on the agenda for the IESG telechat on December 16.

Peter

On 11/29/10 6:45 PM, Richard L. Barnes wrote:
> Hey Adam,
> 
> I'm OK letting the remainder of these go as you prefer.  Thanks for
> working this through with me.
> 
> --Richard
> 
> 
> 
> On Nov 29, 2010, at 7:04 PM, Adam Barth wrote:
> 
>> On Mon, Nov 29, 2010 at 3:18 PM, Richard L. Barnes
>> <[e-mail]> wrote:
>>>>> Minor issues:
>>>>> 
>>>>> [General] It would be very helpful if this document had a
>>>>> summary of changes from RFC 2965, and possibly from RFC 2109
>>>>> as well.  In particular, the fate of the Cookie2 and
>>>>> Set-Cookie2 header fields is a little unclear.  If the intent
>>>>> of obsoleting 2965 is to deprecate the use of these fields,
>>>>> it would be good to state that explicitly.
>>>> 
>>>> The plan is to obsolete RFC 2965 and move it to historic(al).
>>>> Is there a better way of stating that the use of Cookie2 and
>>>> Set-Cookie2 is deprecated?
>>> 
>>> I was thinking something obvious at the end of Section 1, like
>>> maybe "In particular, in moving RFC 2965 to Historic and
>>> obsoleting it, this document deprecates the use of the Cookie2
>>> and Set-Cookie2 header fields."
>> 
>> Done.
>> 
>>>>> [General] It's unclear where this document fits on the scale
>>>>> of "documenting existing behavior" to "describing proper
>>>>> behavior".  It seems like the focus should be on documenting
>>>>> a proper behavior that is maximally compatible with existing
>>>>> behavior.  The document should try to clearly distinguish
>>>>> when it is talking about the desired behavior vs. the
>>>>> existing behavior.  The former should be subject to strong
>>>>> requirements "MUSTs" while the latter will have no
>>>>> requirements at all.
>>>> 
>>>> I'm not sure I understand the distinction between the two.
>>>> The document describes a protocol that matches, to a large
>>>> extent, existing implementations of the protocol.  Where
>>>> existing user agents differ from the specified protocol in
>>>> significant ways, the document contains a note explaining the
>>>> difference.
>>> 
>>> Ok, I think I get it now: The all-caps requirements in this
>>> document are basically a maximally safe/interoperable profile of
>>> existing practice.
>> 
>> Yes.
>> 
>>> It might be helpful to state this explicitly in the Introduction
>>> (toward the end, after "actually used on the Internet"): " In
>>> particular, this document does not create new syntax or semantics
>>> beyond those in use today, but neither does it recommend all of
>>> the syntactic and semantic variations in use today.  The
>>> recommendations in this document represent a preferred subset of
>>> current behaviors.  Where some existing software differs from the
>>> recommended protocol in significant ways, the document contains a
>>> note explaining the difference. " That's a little wordy, but I
>>> think it captures what's meant here.
>> 
>> Done.
>> 
>>>>> [S3 P4] It seems like there should be an all-caps requirement
>>>>> here, e.g., that "Origin servers MUST NOT fold multiple
>>>>> Set-Cookie header fields into a single header field".
>>>> 
>>>> Origin servers certainly can fold multiple Set-Cookie header
>>>> fields into a single header field if they desire.  However,
>>>> doing so changes the semantics.  Given the bytes on the wire,
>>>> there's no experiment we can run to see if the origin server
>>>> did or did not perform this folding.  Therefore, a MUST-level
>>>> requirement is inappropriate.
>>> 
>>> As I understand it, folding would cause multiple Set-Cooking
>>> header values to be considered instead as setting one cookie with
>>> many attributes.  Is there a situation where this is "acceptable
>>> or even useful", to quote RFC 2119?  It seems to me like folding
>>> is virtually guaranteed to be a bug.
>> 
>> Ok.  I've changed this to a SHOULD.  I suspect, actually, that
>> this requirement already exists in the document (in an obtuse way)
>> because the recommend grammar for servers won't produce a "," in
>> the right syntactic surrounds to be a folded Set-Cookie header.
>> 
>>>>> [S4.1.1 P1] It seems like it should be MUST NOT instead of
>>>>> SHOULD NOT: "Servers MUST NOT send Set-Cookie headers that
>>>>> fail to conform to the following grammar:".
>>>> 
>>>> This requirement was discussed at length in the working group.
>>>> I advocated for a MUST-level requirement here as well.
>>>> However, some members of the working group felt strongly that
>>>> the server ought to be able to make use of the full cookie
>>>> protocol as specified in Section 5.  Therefore, we reduced this
>>>> requirement from a MUST to a SHOULD.
>>> 
>>> Seems like the principle of being conservative in what you send
>>> applies here, but if this was considered and rejected by the
>>> working group, I'm not hard over.
>> 
>> It's difficult for me to accept your recommendation here because I 
>> agree with you, but the working group decided to go the other way.
>> We could try to raise the issue again, but it doesn't seem
>> worthwhile.
>> 
>>>>> [S4.1.1 P5] Seems like the SHOULD NOT should be "MUST NOT
>>>>> produce more than one attribute with the same name".
>>>> 
>>>> See my response to S4.1.1 P1.
>>> 
>>> Same response applies -- given that the server doesn't know how
>>> these multiple attributes will be interpreted by a user agent, is
>>> there a situation where this is "acceptable or even useful"?
>> 
>> Acceptable, of course, is a normative notion.  We're defining what
>> is acceptable in this document.  We can define whatever we like to
>> be acceptable.  Usefulness, however, is extrinsic.  I don't think
>> it's particularly useful to send duplicate attribute values, but,
>> on the other hand, nothing terribly bad happens if you do.
>> 
>> I don't feel that strongly about it either way.  My sense is that 
>> having this be the one MUST-level requirement for servers is kind
>> of silly though.
>> 
>>>>> [S4.1.1 P6] Either this should be a "MUST NOT" or it should
>>>>> define which a user agent MUST accept -- or both.  The third
>>>>> paragraph of 4.1.2 seems to imply that the user agent MUST
>>>>> accept the last one (in order of appearance in the HTTP
>>>>> header).
>>>> 
>>>> The user agent requirements are contained in Section 5.
>>> 
>>> Specifically, in S5.3, Step 11.  Might help to note when it does
>>> make sense for this to happen, i.e., when the domain or path
>>> differ, and conversely, to warn that there's no point to sending
>>> more than one Set-Cookie with all three of these the same.
>> 
>> I'm not sure that's needed.  I suspect we could think of use cases
>> for multiple redundant Set-Cookie headers if we thought about it
>> long enough.
>> 
>>>>> [S4.1.1 P8] Again, "SHOULD" -> "MUST"
>>>> 
>>>> See my response to S4.1.1 P1.
>>> 
>>> Same response applies -- given that the server doesn't know how a
>>> non-rfc1123 will be interpreted by a user agent, is there a
>>> situation where this is "acceptable or even useful"?
>> 
>> Well, here there are tons of servers that send every kind of nutty 
>> date format imaginable.  Does that mean its acceptable or even
>> useful, I'm not sure.  I suspect they find it useful because they
>> happen to have the date sitting around in that format.  Saying
>> servers MUST use rfc1123 would just be a joke.
>> 
>>>>> [S8.1] I find this paragraph vague and confusing.  I would
>>>>> suggest separating protocol vulnerabilities from
>>>>> implementation vulnerabilities.  Suggested text: " 
>>>>> Transport-layer encryption, such as that employed in HTTPS,
>>>>> is insufficient to prevent a network attacker from obtaining
>>>>> or altering a victim's cookies.  The cookie protocol itself
>>>>> allows cookies to be accessed or modified from other contexts
>>>>> (subdomains, subordinate paths, or other ports) and some user
>>>>> agents do not even provide the separations required by the
>>>>> protocol.  (See "Weak Confidentiality" and "Weak Integrity",
>>>>> below). "
>>>> 
>>>> I'm not sure I agree with your diagnosis.  All the issues
>>>> described in that paragraph are vulnerabilities in the cookie
>>>> protocol.  None of them are implementation vulnerabilities.
>>> 
>>> I understood phrases like "Cookies do not always provide
>>> isolation by path" and the corresponding examples to mean that
>>> browsers are not enforcing the constraints implied by the
>>> attributes (e.g., the Path attribute).  Do you mean to say while
>>> setting the Path attribute restricts access via the specific
>>> channel of the Cookie header, it does not restrict access by
>>> other methods, e.g., client-side scripting?
>> 
>> If one thing is isolated form another, it should have both its 
>> confidentiality and integrity protected.  Cookies provide some
>> amount of confidentiality but not very much in the way of
>> integrity.
>> 
>> Also, notice, that because this specification describes what user 
>> agents do, it's somewhat non-sensical to say that user agents are
>> not enforcing the constraints implied by the attributes.  If they
>> weren't, we'd updated the list of constraints.
>> 
>>> If that's the case, suggest the following: " Transport-layer
>>> encryption, such as that employed in HTTPS, is insufficient to
>>> prevent a network attacker from obtaining or altering a victim's
>>> cookies.  The cookie protocol itself allows cookies to be
>>> accessed or modified by other HTTP services (subdomains,
>>> subordinate paths, or other ports).  In addition, restrictions
>>> set within the cookie protocol are applied only to access via the
>>> Set-Cookie and Cookie headers, and are not necessarily enforced
>>> for other mechanisms of accessing a user agent's cookie store
>>> (e.g., client-side scripting).   (See "Weak Confidentiality" and
>>> "Weak Integrity", below). "
>> 
>> You keep trying to shift the blame elsewhere.  The problem is not 
>> other mechanisms for accessing cookies.  The problems are in this 
>> document here.  The current paragraph doesn't mince words.  This 
>> protocol, as widely used and important as it is, has some pretty
>> bad security properties.  Somehow, the world hasn't ended yet,
>> though.
>> 
>>>>> Nits/editorial comments:
>>>>> 
>>>>> [S5.1.1] Just as in Section 5.2, it would help to explain
>>>>> here why you're not just using the rfc1123 grammar (from
>>>>> above and RFC 2616 S3.1.1).  E.g.: " NOTE: This grammar is
>>>>> more general than the sane-cookie-date grammar used in the
>>>>> definition of the Set-Cookie header. This allows user agents
>>>>> to interoperate with servers that do not implement this
>>>>> specification. "
>>>> 
>>>> This is already explained two paragraphs earlier:
>>>> 
>>>> [[ For historical reasons, the full semantics of cookies (as
>>>> presently deployed on the Internet) contain a number of exotic
>>>> quirks. This section is intended to specify the Cookie and
>>>> Set-Cookie headers in sufficient detail to allow a user agent
>>>> implementing these requirements precisely to interoperate with
>>>> existing servers. ]]
>>> 
>>> Ah, I didn't read it that way. Maybe just add a particular note
>>> at the end of that: "The grammars used in this section are thus
>>> more general than those recommended for servers in Section 4."
>> 
>> I think that's more confusing than useful.  In particular, there
>> is only one grammar in this section, and its just the universal
>> grammar.
>> 
>>>>> [S5.1.1] It would be helpful to introduce the found-* flags
>>>>> at the beginning of step 2.
>>>> 
>>>> They're already introduced:
>>>> 
>>>> [[ Note that the various boolean flags defined as a part of the
>>>> algorithm are initially "not set". ]]
>>> 
>>> Just think it might make for easier reading and implementation if
>>> I knew up front what booleans I have to be keeping track of,
>>> instead of discovering their names as I go through.
>> 
>> Done.
>> 
>>>>> [S5.1.1 Step5] "the cookie-date if" -> "the cookie-date if
>>>>> any of the following conditions are true:"
>>>> 
>>>> Making that change would make that sentence grammatically
>>>> incorrect.
>>> 
>>> Elementary Rule of Usage number 7 from Strunk & White (4th
>>> edition): "Use a colon after an independent clause to introduce a
>>> list of particulars, anappositive, an amplification, or an
>>> illustrative quotation."
>> 
>> Thanks for quoting Strunk & White, but notice that the current
>> text does not have a colon.  It's actually just one sentence broken
>> over multiple lines (with some fancy bullets thrown in for good
>> measure).
>> 
>>>>> [S8.2] It might be helpful to have a reference or two here,
>>>>> e.g., explaining XSRF attacks and mitigations.
>>>> 
>>>> Sure.  Which references do you suggest?
>>> 
>>> I don't have any especially good ideas.  How about this one?  :) 
>>> <http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf>
>>>
>>> 
... or one of its many references.
>> 
>> Haha, now you're just trying to flatter me.  Done.
>> 
>> Adam
>