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

[Adam Barth <[e-mail]>]

Uploaded:

http://www.ietf.org/id/draft-ietf-httpstate-cookie-19.txt

Thanks,
Adam


On Thu, Dec 2, 2010 at 11:16 AM, Peter Saint-Andre <[e-mail]> wrote:
> 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
>>
>
>