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

On 09/21/2017 10:54 AM, Kyle Rose wrote:
> 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

"Additional connections" of course refers to retries, not replays.  But
perhaps it was felt that the two are similar enough that the concern
still merits a mention.


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

My reading is the implication that some other server in a cluster might
have processed it, yes.
With respect to section 6.2, there has also been some discussion of
"it's always okay to defer processing until the handshake completes,
even if you would have been okay processing it as early data", I think
even with examples of when that may be desirable but I don't remember
any offhand.  And in a discussion of potential mitigation techniques I
think it's reasonable to not assume that some other rule, only specified
later in the document, is always in play -- that rule is itself part of
the mitigation techniques!

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

I agree that additional clarification is in order.
As some potentially helpful additional information, much of the text in
the document is shaped by consideration of HTTP proxies that do not
necessarily behave as a CDN that is authoritative by policy for the origin.

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

Sure.

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

Sigh ... there probably does need to be normative language, yes.
And yes, that's a can of worms.

-Ben


> All that aside, I like this proposal a lot.
>
> Kyle
>