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

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

Forwarding to [e-mail] to keep the WG in the loop...

/psa

-------- Original Message --------
Subject: Gen-ART LC review of draft-ietf-httpstate-cookie-18
Date: Sun, 28 Nov 2010 15:47:49 -0500
From: Richard L. Barnes <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-httpstate-cookie-18
Reviewer: Richard Barnes
Review Date: 28 November 2010
IETF LC End Date: 2 December 2010
IESG Telechat date: (unknown)

Summary: This document is close to being ready for publication, but
could benefit from several clarifications and upgrades to requirements
language.  In particular, user agent security requirements need to be
slightly stronger.


Major issues:

[S8.6] Many of these integrity issues are caused by user agents
accepting cookies from outside the context where they would send them,
in particular with the Secure and Path attributes.  It seems like this
document, in specifying the desired/proper behavior of user agents,
should require behavior that would mitigate these attacks.  In direct
parallel to the handling of the Domain attribute:
1. Set-Cookies with the Secure flag should only be accepted over secure
channels
2. Set-Cookies with the Path attribute set should only be accepted if
the path value matches the request-uri of the request
(That is, update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10) I
realize that as long as there are legacy user agents out there, servers
can't rely on these protections, but if any user agents implement these
requirements, then fewer transactions will be subject to these attacks.


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.

[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.

[S2.3 P2] Is the request-host the same as the value of the HTTP/1.1 Host
header field?

[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".

[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:".

[S4.1.1] Is there a reason that path-value is so unconstrained?  Based
on S5.1.4, I would have expected it to be abs_path (from RFC 2396).

[S4.1.1 P5] Seems like the SHOULD NOT should be "MUST NOT produce more
than one attribute with the same name".

[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).

[S4.1.1 P8] Again, "SHOULD" -> "MUST"

[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).
"


Nits/editorial comments:

[S2.1 P3 "not intended to be performant"] I'm not sure the word
"performant" has the meaning that seems to be intended here.  (The
definitions I'm finding indicate "one who performs".)  Should probably
expand to "not intended to require the performance of specific steps".

[S3 P2 "the default scope"] The notion of the "scope" of a cookie was
only briefly introduced in the Introduction.  Could be good to remind
the reader in the first paragraph.  "... the user agent will return in
future HTTP requests." -> "... the user will return in future HTTP
requests that are within the scope of the cookie".

[S4.1.1 P9] The paragraph as it stands is kind of useless -- what am I
supposed to do with this information?  Suggest changing to:
"
Some user agents represent dates using 32-bit UNIX time_t values.  These
user agents will process dates after January 19, 2038 incorrectly.
Origin servers SHOULD NOT set expiration times later than this time.
"

[S4.1.2] The phrase "Non-Normative" seems inapt here.  Suggest changing
the heading to something like "Summary of Semantics".

[S4.1.2.3 P1 "... only to the origin server"] It would be helpful to
clarify here by adding "... and not any sub-domains".

[S4.1.2.6] It could be helpful here to note that the "HttpOnly"
attribute is not the opposite of the "Secure" attribute (which one might
initially imagine as "HttpsOnly"), and thus that setting them both is
not a contradiction.

[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.
"

[S5.1.1] It would be helpful to introduce the found-* flags at the
beginning of step 2.

[S5.1.1 Step5] "the cookie-date if" -> "the cookie-date if any of the
following conditions are true:"

[S5.1.1 Step5] I don't understand why the year 1601 is a cutoff here.
Wouldn't any past date be usable to kill a cookie?

[S8.2] It might be helpful to have a reference or two here, e.g.,
explaining XSRF attacks and mitigations.


_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf