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

Hi Willy,

On 07/30/2017 11:02 PM, Willy Tarreau wrote:
>
>> 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.

Okay, I'm happy to support that :)

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

Just to double-check, we will still have text that says the server farm
must act consistently (as opposed to just saying "the server must do
this" and making it implicit that a server-cum-server-farm is bound to
behave as if a single server)?

> 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

This is very reassuring for me to hear, thank you.

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

The server is supposed to send its
ServerHello/EncryptedExtensions/Finished immediately after it sees the
ClientHello, and the client can keep streaming early data while that's
happening.  The client should send EndOfEarlyData/Finished once it
receives the server's Finished, and move the data stream to 1-RTT data. 
So I think that the attacker can let through the ClientHello but hold on
to the application data until the server's first flight arrives, then
let through the stored records along with the client's response, all in
one go (possibly with additional delaying for the whole assembly).

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

Sounds good.

Thanks,

Ben