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

Hi Willy,

On 08/01/2017 02:16 AM, Willy Tarreau wrote:
>> 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.

I think we may still be talking past each other, here, specifically
about the "no[t] reusable for another [connection]" point.  When we talk
about the specific bits of early data that go on the wire, wrapped in
one or more TLS records, those can only ever be used on one (successful)
TLS connection because the encryption key incorporates the
ClientHello.random and compliant clients will not reuse the random
value; the client only accepts one ServerHello and that commits the
connection to being between those two parties (or to failing).  At the
same time, anyone who records those TLS records on the wire can replay
them at the same or a different server, with the intention of inducing
the server to send an application-level response to the unauthenticated
(imposter) client, even before the ClientFinished is received (which
will never happen).  The server farm has some limited amount of control
over how often this will happen, but in general it cannot be completely
prevented, regardless of whether or not the ClientFinished is processed
on the "real" connection -- the replay avoidance strategies discussed in
the TLS 1.3 spec all come into play at the time of the decision of
whether or not to accept the early data TLS extension, which is well
before a ClientFinished is available.

So, I don't think I understand what you mean by "specific to this
connection and no[t] reusable for another one".  Am I missing something?

Thanks,

Ben