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

From: Kyle Rose <[email-masked]>
Date: Thu, 21 Sep 2017 11:54:39 -0400

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Sep 2017 14:26:43 -0500

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

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

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

> "with the client" after "handshake" just to make it blazingly obvious.

Sure.

> 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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Sep 2017 04:33:06 +0200

Hi,

> > "with the client" after "handshake" just to make it blazingly obvious.

In fact I'm a bit at fault on some of these points because I wanted to
add a diagram showing the different steps that could be referenced in
the text, but failed to find time to do it :-(

> And yes, that's a can of worms.

In fact I think we could add this as a prerequisite for accepting unvalidated
early data. Something more or less like this (but with a better wording) :

  A server MUST NOT use early data before the handshake completes if it is
  part of a cluster in which other members may possibly apply a different
  treatment to the same request. A gateway MUST NOT process a request
  received using early data if it is uncertain that all downstream server
  instances will apply the same treatment to the request, or if it is
  uncertain that other gateways exist with a possibly different behaviour.
  In both situations, if the receiving host sees the TLS connection, it MUST
  wait for the handshake to complete before processing the request. If it
  receives a request containing the Early-Data header field, it MUST respond
  with a 4NN (Too Early) status code without processing the request.

Willy

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 Sep 2017 08:17:53 -0500

>   with a 4NN (Too Early) status code without processing the request.

At risk of adding too many words, I submit:

"In some deployments the TLS server functionality is provided by a
cluster or pool of independent machines that share credentials and key
material for server authentication and session resumption, subject to
some form of load balancing.  In order to safely process early data
before the handshake completes, such deployments also need to share a
common algorithm for determining whether a given HTTP request is safe to
begin processing before the handshake completes.  A server MUST NOT act
on early data before the handshake completes if it belongs to such a
cluster or pool and there is not such an agreed algorithm for
determining request safety.  Similarly, a gateway MUST NOT process a
request received in early data absent knowledge that all downstream
gateways and/or server instances will use the same algorithm for
determining whether the request is safe to process as early data.  In
both the server-in-pool and gateway cases, if a request is received
containing the Early-Data header field, the server MUST respond with a
4NN (Too Early) status code without processing the request; if the
Early-Data header is not present but the request is received in early
data, the server MUST wait for the handshake to complete before
processing the request or respond with a 4NN (Too Early) status code
without processing the request."

-Ben

---

From: Kyle Rose <[email-masked]>
Date: Fri, 22 Sep 2017 12:38:17 -0400

On Fri, Sep 22, 2017 at 9:17 AM, Benjamin Kaduk <[email-masked]> wrote:
> "In some deployments the TLS server functionality is provided by a cluster
> or pool of independent machines that share credentials and key material for
> server authentication and session resumption, subject to some form of load
> balancing.  In order to safely process early data before the handshake
> completes, such deployments also need to share a common algorithm for
> determining whether a given HTTP request is safe to begin processing before
> the handshake completes.  A server MUST NOT act on early data before the
> handshake completes if it belongs to such a cluster or pool and there is not
> such an agreed algorithm for determining request safety.

I don't think this is sufficient: the agreed-upon algorithm could be
to accept if the server IP is odd and reject if the server IP is even,
but that would violate the consistency constraint.

I think we want something like "A server MUST NOT act on early data
before the handshake completes if it and another server in the same
cluster or pool could, given the same early data, disagree on whether
to process that data prior to handshake completion or not."

Kyle

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 23 Sep 2017 06:34:16 +0200

> to process that data prior to handshake completion or not."

I think it covers it all like this. I'd add "The same rule applies to
gateways". Benjamin's proposal is more exhaustive but I think that
your sentence above is sufficient considering that the expected actions
are already covered in the rest of the spec.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Sep 2017 08:47:20 +1000

Thanks for reading Kyle,

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

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

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

> forward reference to the next section.

Fixed.

> 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

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.

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

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Sep 2017 10:30:38 +1000

> On 28 Sep 2017, at 8:47 am, Martin Thomson <[email-masked]> wrote:
> 

Yes. From the UA's perspective (and any proxies, configured or not), a gateway is the origin server -- even though the common CDN term for the customer's back-end server is also "origin."

We tried to clarify this in prehistoric times (I can dig up a draft of mine from the 90's if you like) with the horrible term "Surrogate Origin Server" -- thankfully, that seems to have *mostly* not stuck.

Now, let's talk about "upstream" and "downstream"...

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Sep 2017 10:35:02 +1000

> consequences of replay are not significant."

We agonised over this in httpbis, and came up with <http://httpwg.org/specs/rfc7231.html#rfc.section.4.2.1>. Saying "alter server state" is too broad, since it can include things like logs, TCP state, etc. etc. What's important is 1) resource (not server) state, and 2) whether the effects are significant -- which is necessarily a judgement call. The important thing is that the party making that judgement do so with an appropriate amount of information -- which this draft is helping enable.

Cheers,

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Sep 2017 10:46:01 +1000

> We agonised over this in httpbis, and came up with <http://httpwg.org/specs/rfc7231.html#rfc.section.4.2.1>. Saying "alter server state" is too broad, since it can include things like logs, TCP sta…

So maybe...

"In general, if processing a request does not alter resource state in
a way that would affect subsequent requests, the consequences of
replay are not significant."

?

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Sep 2017 10:50:05 +1000

> On 28 Sep 2017, at 10:46 am, Martin Thomson <[email-masked]> wrote:
> 

No - sometimes the changes might not affect subsequent requests (e.g., a drop box where the outcome isn't user-visible).

I prefer the current text in the draft; it's aligned with and refers to 7231.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Sep 2017 10:57:33 +1000

> I prefer the current text in the draft; it's aligned with and refers to 7231.

I can certainly live with that if others can.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Sep 2017 08:43:32 +1000

FYI, I just merged:

> https://github.com/httpwg/http-extensions/pull/408
> https://github.com/httpwg/http-extensions/pull/409

That accounts for all of the open comments.  If I botched these, or
you have something more, we can make some more issues and PRs.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 28 Sep 2017 19:19:11 -0400

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

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

> consequences of replay are not significant."

I'll address this later in the thread.

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

LGTM.

> https://github.com/httpwg/http-extensions/pull/407

Both of these also look good. Thanks.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Thu, 28 Sep 2017 19:33:13 -0400

> I can certainly live with that if others can.

The section of the HTTP/1.1 standard Mark referenced uses the language
"the client does not request, and does not expect, any state change on
the origin server as a result of applying a safe method to a target
resource", and in the next paragraph clarifies that this judgment must
be made by the client alone, presumably because it has no way of
knowing what the server is actually doing, and that "the client did
not request that additional behavior and cannot be held accountable
for it".

In this case, the origin server knows (or could know) what the effects
of the request are, so the two situations are different.

ISTM also that "state-changing side effects" can easily be construed
to include logs, TCP state, etc., so the same objection seems to apply
here.

That said, I fear any language here will either be too specific and
therefore wrong, or too general and therefore permit some undesirable
origin server behavior.

Kyle

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Sep 2017 09:53:19 +1000

> that is sufficiently normative that a repeated ClientHello is

I've just removed the offending text.  Thanks.

> therefore wrong, or too general and therefore permit some undesirable

I think that the intent is clear enough.  If not from here, from
elsewhere in the draft.  As Mark says, the text is correct from the
standpoint of the established terms in 7231 (I also find this obtuse
and arcane, you aren't the only one).  So I think that we might just
have to leave it.