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

On Wed, Sep 27, 2017 at 6:47 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> 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.)

The TLS draft does call the client's Random a "nonce", so hopefully
that is sufficiently normative that a repeated ClientHello is
exceptionally unlikely.

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

I read the remainder of the thread on this topic, and Mark's email
sufficiently cleared this up for me. It sounds mostly like a matter of
different jargon files.

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

I'll address this later in the thread.

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

LGTM.

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

Both of these also look good. Thanks.

Kyle

Received on Thursday, 28 September 2017 23:19:34 UTC