Re: Review of draft-thomson-http-replay-latest

On 4 August 2017 at 15:53, Victor Vasiliev <> wrote:
>> As I noted in #28 above, even if the handshake
>> completes, it doesn't mean that the once-early data is entirely safe.
> I am not sure I can read that from #28, I seem to read it as the opposite?
> I might be confused here.
> I am not sure I understand in which sense it's not safe.

The problem I'm concerned about is the one that Subodh described, one
where you have two connections:

1. a completed handshake where the server processes the request on the
assumption that it is safe to do so (because it is now past the

2. a replayed handshake where the server processes the request
differently prior to the handshake completing

If the processing in 1 wasn't cognizent of the potential for 2, the
server might leak information in its processing at 1 (for instance, by
making decisions based on the results of the processing that happened
at 2).

An example: say that the processing involved an idempotent update of a
stored value.  That's safe to do before the handshake is complete if
that is all that happens.  However, this request might produce a
response that is still non-idempotent.  If the value changes, the
server might echo the previous value in the response.  The processing
seems safe to do immediately - on its own it would be idempotent - but
the response generation isn't (the presence or absence of the previous
value exposes information through the length of the message), which
demonstrate that the logic is flawed.  Even deferring response
generation until after the handshake completes, if the information
that it acts on was generated before the handshake.

That's the sort of understanding I wanted to convey with #28.  That
is, without going too much into detailed examples like that.

>> This goes back to the need for consistent handling.
> Could you elaborate on the concept of consistent handling?  I've read #27,
> and I still can't quite understand what problem you are trying to solve.

I probably got this confused with a separate issue there.  Consistent
handling is more to prevent inadvertent creation of leaks when
processing a request.  If requests are sometimes processed by nodes
and deferred until handshake completion by other nodes, then the nodes
that process the requests expose information.  For the replay defenses
to be effective (either delay or 425), the application of those
defenses needs to be consistent across all nodes.

Received on Friday, 4 August 2017 06:21:25 UTC