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 <[email protected]> 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 _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
