Questions and comments about draft-ietf-httpbis-replay-00

Section 3, bullet 2: I'm not clear on how "Assuming that a replayed
ClientHello will not result in additional connections being made by
the client" impacts replay protection, or why waiting until the
handshake completes only provides the server with "some" assurance
that the early data was not replayed. Under what conditions could
early data replay result in two completed handshakes? Or is the
implication here that some other server in a cluster might have chosen
to process early data immediately? Assuming different policies on
different servers in a cluster complicates the analysis, and seems to
be precluded by the consistency requirement of section 6.2.

Section 3, paragraph after bullet 4: Does "origin server" in this case
refer to any box that is not oblivious to the semantics of a request?
This statement might be confusing for those in the CDN industry for
whom "origin server" is a term of art referring to the customer's web
server infrastructure and not to the CDN proxy, which is often (by
policy) equally authoritative despite having to go to the origin
infrastructure to satisfy some requests.

Section 3, same paragraph: This is a minor nit about the use of the
phrase "side effects": I think of a GET that modifies state as having
a state-changing side effect, whereas PUT, DELETE, and POST have
state-changing *primary* effects.

Section 4, last paragraph: I think the "Early-Data" header field is a
forward reference to the next section.

Section 5.1: "An intermediary that forwards a request received in TLS
early data..." Partially or fully? Based on the properties of TLS 1.3
0-RTT (and as restated in section 2, paragraph 2), a request that is
not acted upon until at least one byte of post-handshake data has been
received is effectively not early data in the sense that it is known
not to have been replayed on this connection; but a request that may
be partially processed (somewhere) based only on early data *is* an
early data request. I think more precision is needed here. Also, like
section 3, bullet 2, the implication that different servers might
treat the same early data differently conflicts with the consistency
requirement of section 6.2.

Section 6.1: "A gateway that isn't certain about server support SHOULD
either delay forwarding the request until the TLS handshake
completes..." Obviously this is talking about the TLS handshake
between the client and the gateway, but it might be worth adding a
"with the client" after "handshake" just to make it blazingly obvious.

Section 6.2: Does there need to be normative language enforcing this
consistency constraint? If so, that opens a can of worms when servers
might have different behavior over time and no shared state.

All that aside, I like this proposal a lot.

Kyle

Received on Thursday, 21 September 2017 15:55:03 UTC