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

Hi Ben,

On Mon, Jul 31, 2017 at 10:36:02AM -0500, Benjamin Kaduk wrote:
> > 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)?

Yes I think it is important. I'd even be willing to go a bit further
regarding consistency requirements. Something along "The first intermediary
on the path which cannot guarantee that the next hops will act consistently
and that they will all properly handle the Early-Data header field MUST
either wait for ClientFinished if it's the first one to receive early data,
or respond with 4NN without forwarding the request".

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

Yes but then the EarlyData have already been sent to the server, and the
intercepted data are specific to this connection and nor reusable for
another one, that was my point.

Cheers,
Willy

Received on Tuesday, 1 August 2017 07:17:00 UTC