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:
>
> 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:
> Received on Thursday, 28 September 2017 23:19:34 UTC