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

Thanks for reading Kyle,

On Fri, Sep 22, 2017 at 1:54 AM, Kyle Rose <krose@krose.org> 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
> 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.

The assumption is simpler than you are imagining.  It says that as
long as the client isn't willing to create two connections with the
same ClientHello, we're good.  (Maybe that was too clever.)

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

Origin server uses the definition in RFC 7230.  That is, the actual
authority for the resource.  A gateway is an apparent authority, but
at the point that it forwards a request the server that it forwards to
becomes the true authority (or something close to that).

Yes, it intentionally refers to the customer of the CDN.  For those
requests that the CDN considers itself able to fulfill, it is the
origin server.

(I hope that is consistent with others' understand of the definitions
of these terms.  We sort of naturally assume that the roles are
strictly binary, when they really aren't, as you point out.)

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

I want to get the sense of the group here, I think that changing
server state is what we want.  Can I reword this to:  ?

"In general, if processing a request does not alter server state, the
consequences of replay are not significant."

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

Fixed.

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

You are right, see PR: https://github.com/httpwg/http-extensions/pull/408

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

I think that the bullet is OK.  We cover the caveats and specifics
later (several times in fact), but the bullet is still correct at the
level of detail it is addressing.  More detail here would only make it
harder to comprehend.

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

Fixed, thanks.  I also change a few "server" instances to "origin
server" to be flamingly overt.

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

I have taken and tweaked your proposed text, which I think is just
about right: https://github.com/httpwg/http-extensions/pull/409

Note that PR 408 (above) adds text to the same section for gateways,
so I think that I don't need Willy's friendly amendment, assuming that
we all like 408.

Finally, I have a final change that addresses the last issue on the
tracker (regarding out of order delivery of early data).  It wasn't in
your feedback, but I thought that I'd float it anyway:
https://github.com/httpwg/http-extensions/pull/407

Received on Wednesday, 27 September 2017 22:47:43 UTC