Re: New Version Notification for draft-thomson-http-replay-00.txt

Hi Ben,

On Fri, Jul 28, 2017 at 08:27:40AM -0500, Benjamin Kaduk wrote:
> I think we've been at least partially talking past each other, and I can
> take the blame for some of that -- you seem to have been trying to keep
> a narrow focus on the question of whether the Early-Data header is sent
> on the first hop, and I've been expounding on various other potential
> issues in the 0-RTT ecosystem that are not really relevant to that more
> narrow question.

No problem and no blame to get here. The subject is complex and it's
important to ensure that the model is reliable and provides some value.

> > precisely the limit of using 0-RTT, so if the whether *one* of the servers
> > considers the request safe or not (configuration issue or anything) is out
> > of our control. The principle is to let the server decide what action to
> > take with requests received as Early Data.
> >
> 
> I'm not sure I understand what you mean by "precisely the limit of using
> 0-RTT".  If I can attempt to rephrase what you're saying here it would
> be that "we need to make sure that the server knows a given request was
> (partially) received as early data (at some point in the chain), and the
> server gets to decide whether it's safe enough to reply to right away. 

Yep.

> We can cover the consistency of behavior across servers as well, but
> that is a separate issue."

No we can't even cover it, it has to be a prerequisite for implementation.
In fact we're documenting how to use a risky but very appealing feature
safely with HTTP and posing some elements so that it doesn't represent a
risk anymore. When we write "the server must do this", if it's a server
farm and not a single node, they all have to act consistently. If there
is a risk of inconsistency past a certain point, it becomes the front
intermediary's role to either respond with 4NN or wait for ClientFinished
to ensure reliability before the uncertain path.

I think it's very important to document a number of risks to be clear
about whether or not 0-RTT can be safe to use in certain deployments.
Many users have no idea about these risks and are willing to put it
anywhere without any check. I've been asked repeatedly "when will haproxy
implement 0-RTT", and I always replied "never until it's safe to use
with HTTP".  Then "but others are already using it so surely it's safe"...
Here we know it's not always the case and that it must be clear when it
is and when it is not. With appropriate documentation, implementers will
know that they'll do 0-RTT till the gateway, wait for ClientFinished here
and always protect unsafe servers. Others will do this only for application
servers and will let requests for static contents to go to the static farm
with only the early-data header field set because the risks will be
understood.

> >> My understanding was that Subodh's point involve delaying not just the
> >> ClientFinished but also the early data preceding it, so that Bob did not
> >> even know there was a request at all, let alone one that is not
> >> finalized.
> > Not exactly since the Early Data has to be sent before the ClientFinished,
> > the point was to be able to present Bob with a request carrying a validated
> > ClientFinished (ie: Bob was supposed to trust it).
> 
> The point was to be able to present Bob with such a request, yes.  But
> we also require that Bob does not just go ahead and process the request
> without the ClientFinished, since then he would not be treating it as
> validated early data.
> Thinking about it more (and without presuming a specific set of
> requirements of the many we are considering), the necessary situation
> could be obtained in at least two ways: (1) blocking both the early data
> and the ClientFinished, or (2) only blocking the ClientFinished and
> relying on Bob using the strategy of "wait for ClientFinished before
> processing the request".  In my previous mail I was only considering (1)
> to the exclusion of (2); sorry about that.

No pb. But (1) doesn't work. You can't block early data *and* ClientFinished
because ClientFinished comes after the RTT as a response to the server
handshake, which will not come before the early data are sent to the server :-)

> Saying "the second will fail" without qualifications makes me a little
> nervous, as it depends on the server's behavior/the consistency across
> servers.  But I think I see what you are getting at, and agree.

Great ;-) Keep in mind that our responsibility is to write "if you can't
ensure consistency across your farm, the intermediary fronting this farm
must return 4NN".

Cheers,
Willy

Received on Monday, 31 July 2017 04:02:34 UTC