-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. First of, I think the draft is well written and a good read, compliments to the authors, especially the examples were helpful! To start with the Security Considerations (section 6), there aren't any..... or rather, section 6 refers to the security considerations of part 1 and states that the security considerations are the same as for HTTP in general. IMO that is a bit too easy, for example throughout the text there is discussion about clock synchronization, evaluation of weak conditionals, hashes etc. All of those can lead to the client having a "wrong" view of the resource. I would expect some discussion as to what that could mean and what measures could be taken to avoid that. Also, in part 1, security considerations 8.5 there is some discussion about MitM attacks and evil proxies, and the general statement is made that proxies should not be trusted anymore than the person who operates it. Whereas it is true that everyone in the path can change the transmitted information at will, I could imagine that with ETags one could actually implement some rsort of integrity protection by using ETags that are signed hashes of the content that is transfered.... thinking out loud... anyway, my bottom line is that I am not sure that the security properties of the system as a whole don't change by introducing conditionals. Then other things that came to mind while reading the draft (many just edutorial): - - section 1, p3, Introduction, first sentence I can not parse that sentence, should it perhaps be "....on that metadata be checked...." -> "....on that metadata; to be checked...."? - - 1.1, p3, conformance and error handling, 3d paragraph I don't get the statement about "SHOULD-level" requirements. Isn't that always the case with SHOULD? I.e. what is different from RFC2119? - - 1.2, p4, Syntax I think it would be helpful to state what OWS, obs-text and HTTP-date (informal) stand for, the production rule given here does not provide much clarity - - 2.1, p5, weak vs strong, 4th paragraph "A cryptographic hash function", which one? I think you need to state at least that you should choose one that is collusion resistant (and this should probably go into the security considerations) - - 2.2, p6 last-modiefied This paragraph came a bit out of the blue it is not mentioned that Last-Modified is one of the validators that you just talked about in the previous paragraph - - 2.2.1, p7, generation, one but last paragraph Seems that a bad system clock can nevertheless screw things up, if the system clock is set to earlier than the previous "fresh page" the content will never be updated. - - 2.2.2 p7, comparision Is it really neccessary to have the elaborate determination whether the vlaidator is weak or strong, with arbitrary time intervals etc.? It seems very error prone and confusing for implementers. Why not just say that Last-Modified is weak, and if you want strong use ETags. - - 2.3 ETag, p9, Note "ought to" is not very normative. Why not make it MUST or SHOULD? - - 2.3 ETag, p9, 2nd paragraph The "more reliable" and "convenient" don't seem to be related, even though that is suggested in the paragraph. I would argue that an entity-tag can be implemented to be more reliable period (because of the clock problems discussed before) - - 2.3.1 p 9, generation same discussion as in 2.1 about collission resistant hashes - - 2.4, p12, Rules.... HTTP/1.1 clients So if I understand the "MUST use the entity-tag" correctly the heuristic that is being used for servers can not be used here. Like in the server example I could imagine that also the client could decide not to fetch new weather data based on some internal rule (because it is mobile and wants to avoid rapid updates for example) The MAY use the Last-Modified in the case of an HTTP/1.0 origin server deserves some explanation, not being an HTTP expert it is unclear to me what makes it deifferent for 1.1 3.1, p 13, If-Match Most HTTP return codes are expanded, highly appreciated! Could you please do that for all, i.e. "304" -> "304 (not modified)" etc., that makjes for a much easier read. 3.3, p16 If-Modified-Since, First Note: What is the consequence of the Range header field modifying the meaning? 3.4 p17, If-Unmodified-Since Why not defining the the result of a request having both an If-Unmodified-Since and a If-None-Match or If-Modified-Since? 4.1 p17, Not modified, second paragraph A 304 response..... isn't this a fine case of a SHOULD rather than a MUST? Or perhaps "A 304 response MUST include a Date header field, unless the origin server.... , in that case a Date header field MUST NOT be provided", and what actually does "reasonable approximation" mean? Once again, compliments on a well written spec! Klaas Wierenga -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VXkgACgkQH2Wy/p4XeFJoDgCgn2tUOZjydxeccRNBm7ml+XcB g+cAoMhPk0yV7KCZRVw+ysYJaQYh9IsQ =Woo2 -----END PGP SIGNATURE-----