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

On 07/27/2017 03:31 AM, Willy Tarreau wrote:
> Hi Martin,
>
> On Thu, Jul 27, 2017 at 05:15:20PM +1000, Martin Thomson wrote:
>> Hi Willy,
>>
>> On 27 July 2017 at 17:08, Willy Tarreau <w@1wt.eu> wrote:
>>> On Wed, Jul 26, 2017 at 02:19:29PM +1000, Martin Thomson wrote:
>>>> If Early-Data was omitted by the client, that would make it easier in
>>>> a sense.  Then an intermediary could tell if it was the first.
>>> If you remember that's exactly the conclusion that draw us to get rid
>>> of this header on the client during our first meeting. We noticed that
>>> it was wrong to have the client provide it because it would confuse
>>> chained intermediaries and in the end the only thing that matters is
>>> not how the request was *sent* but how it was *received*.
>> Yes, this was a good reason until Subodh convinced me that the race
>> was serious and that how the packet is received can be controlled by
>> an attacker to the extent necessary to confuse a server.
> I continue to disagree on this specific case because it's exactly the
> same as what can be done without 0-RTT, and 0-RTT doesn't make it any
> weaker.

I'm not sure that it's "exactly" the same, though perhaps the degree of
difference is only qualitative.  With a well-behaving client and server,
and an attacker in the network, my qualitative expectation is that the
attacker can cause a given request to be processed once as 0-RTT
(actually more in many setups) and once as 1-RTT.  What's different in
Subodh's attack is that the attacker can cause the request to be
processed twice as 1-RTT (and maybe more as 0-RTT), so the number of
1-RTT processings has gone up.

Of course, an attacker doing the analogous thing when TLS 1.2 is in use
would also cause the request in question to be processed twice as 1-RTT,
since there is no 0-RTT available!  So, the main qualitative difference
that seems new here is the server being convinced it did something
"safer" than it actually did.  I've not fully thought out the
implications of this, whether there are plausible scenarios that could
lead to (e.g.) money being spent twice, etc.

> We're "just" talking about a generic way to abuse a supposed ability
> for a client to retry upon network timeouts. This exists in clear, in
> TLS with and without 0-RTT. The attacker can even just block the
> response from being delivered to the client, to ensure it's really
> handled. All that's done here is to provoke a timeout and watch what
> happens.
>
> The draft never suggests at all that a client should retry on timeouts
> met with 0-RTT, it suggests the client has to retry when getting the
> 4NN response, promising the request was not processed.
>
>> It's true that receipt is what matters ultimately.
>>
>> I've updated the PR
>> (https://github.com/martinthomson/http-replay/pull/25) to capture this
>> nuance.  Hopefully it isn't awful.
> I really disagree with one this because it removes the ability to wait
> for the ClientFinished signal for all communications, even with client
> talking directly to the server. It significantly affects the usage scope
> of 0-RTT in my opinion, to try to cover for a case that is already not
> covered using 1-RTT.

I think that one of the key interactions here is that TLS itself is a
two-party protocol, but for this document we are forced to consider
multi-party interactions (chains of TLS connections).  So for any given
TLS connection, waiting for ClientFinished is safe, but the composition
is not, which is where we can get into trouble.

Just tossing a random idea out there -- how crazy would it be to have
the client send Early-Data: 1, but each successive hop incrementing the
value, so we get Early-Data: 2, Early-Data: 3, etc. indicating the
"nesting level"?  That would perhaps permit some of the optimizations
we've talked about, like waiting for ClientFinished when talking
directly to the client.

-Ben

> I'd rather remind of the risks of retrying a failed request upon timeout
> instead of waiting for the proof of non-execution that 4NN consists in, but
> that covers a broader scope, more in line with Mark's initial enumeration
> of all retry cases.
>