Early Review of draft-ietf-httpbis-p4-conditional-
review-ietf-httpbis-p4-conditional-secdir-early-wierenga-2012-04-26-00

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